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(57) Abstract: Methods and system consistent with the present 
invention provide a workflow modeling (206) and project plan- 
ning (212) integration tool that allows a user to model a business 
process or workflow, to create and activate a project plan based 
on the workflow, and to track the progress of the activated project 
plan. The tool also allows the workflow to be reused to create 
more than one project plan based on the workflow. Moreover, the 
tool simulataneously manages the execution of the plans. The in- 
tegration tool may include a Web-based •'Distributed Authoring 
and Versioning" (WebDAV) server (140) that operates as a virtual 
file system for computers on a network to allow more than one 
user on different computer systems to view the same workflow or 
project plan, monitor the progress of an activated project plan, or 
simultaneously create and activate different plans fix>m the same 
workflow. 
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METHODS AND SYSTEMS FOR INTEGRATING PROCESS MODELING AND 

PROJECT. PLANNING 

Cross-Reference To Related Applications 

This application claims the benefit of the filing date of U.S. Provisional Application No. 
5 60/230,054/ entitled *T>evelopment Tool for Modeling Workflow," filed on September 1, 2000, 
and U.S. Provisional Application No. 60/296,707, entitled 'Improved Development Tool For 
Modeling Workflow," filed on June 7, 2001, both of which are incorporated herein by reference. 

The followiag identified U.S. patent applications are also relied upon and are 
incorporated by reference in this application: 

10 U.S. Patent Application No. ' entitled 'TVletiiods and Systems for 

Improving a Workflow Based on Data Mined from Plans Created from the Workflow," bearing 
attorney docket no, TSlOOl, and filed on the same date herewith; 

U.S. Patent Application No. , entitled ''Methods and Systems for 

Animating a Workflow and a Project Plan," bearing attorney docket no. TS1005, and filed on 
1 5 the same date herewith; and 

U.S. Patent Application No. , entitled "Methods and Systons for 

Optimizing Resource Allocation Based on Data Mined from Plans Created from a Workflow," 
bearing attomey docket no. TS1006, and filed on the same date herewith. 

Field Of The Invention 

20 The present invention relates to a method and system for integrating a business process 

or workflow with a project plan. More particularly, the ravention relates to a method and system 
for creating and activating a project plan based on a workflow, for managing the execution of 
the activated project plan, and for tracking the progress of the activated project plan. 

Background Of The Invention 

25 To become more efficient and competitive, businesses and industries have striven to 

capture and streamline the business processes or workflows they use to operate and manage their 
respective enterprises. In general, a workflow is a model of a process. More specifically, a 
workflow can be viewed as a structured set of activities designed to produce a specific output for 
a particular customer (internal or extemal to an enterprise) or market. Although conventional 

30 software tools define the steps performed by the workflow, conventional tools do not schedule 

-1 - 
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the resources (e.g., the people, equipment, or software technologies) responisible for completing 
each activity. Conventional tools also do not prepare a timeline identifying the beginning or end 
of each activity. Thus, conventional tools do not prepare a schedule for completing the 
workflow. 

5 Businesses and industries also use other conventional software tools, such as Microsoft 

Project™, to build and manage a project plan for their respective enterprises. A plan represents 
an instance of the workflow. More specifically, a plan can be viewed as a working schedule for 
a project to produce a product or artifact, such as a computer, bicycle, or. software build, for the 
respective enterprise. These other conventional software tools t3^ically display the working 

10 schedule in the form of an interactive Gantt chart, i.e., a chart to which ttie user can make 
updates. A Gantt chart is the linear, time-based representation of a project schedule, usually laid 
out on a horizontal plane where the times/dates increase to the right These Gantt charts show 
the temporal relationships between the different tasks in a project, where the tasks are arranged 
along the vertical axis. Gantt charts are typically used to lay out an initial plan/timeline for tbe 

15 project, and then to track the actual progress of a project firom start to finish. The modem 
software-based Gantt chart also identifies the resoia:ce(s) req)onsible for completing each task of 
the plan, the dependencies between the tasks, and, once the project has begun, the status of each 
task. 

The conventional tools that support the building and managing of a project plan, 
20 however, do not provide direct links between projects and the workflows or business processes 
that the enterprise has defined and seeks to implement to gain business advantage and 
economies of efficiencies. Likewise, the conventional tools that enterprises use to define and 
manage workflows are not linked to project plans. Because both workflows and project plans do 
not exist on the same tool, workflows and project plans cannot be integrated or synchronized to 
25 keep tiie workflows and project plans "in step" with each other. Thus, there is a need in the art 
for a tool that avoids the limitations of these conventional software tools. 

Summary Of The Invention 

Methods and systems consistent with the present invention provide a workflow modeling 
and project planning integration tool that overcomes the limitations of conventional tools. 
30 Contrary to conventional tools that do not allow a user to integrate a business process or 
workflow with a project plan, the integration tool, in accordance with methods and systems 
consistent with the present invention, allows a user to model a business process or workflow, to 
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create and activate or start a project plan based on the workflow, to manage the execution of the 
activated plan, and to track the progress of the activated project plan. In addition, the tool may 
include a Web-based 'T)istributed Authoring and Versioning" server that operates as a virtual 
file system to allow more than one user to view the same workflow or project plan, to provide 
5 persistent storage, to monitor the progress of an activated project plan, to simultaneously create 
plans from the same workflow, and to have essentially unlimited access to the power of the tool 
tiirough the ubiquity of the Internet. ''Versioning is a term well-known in the art for c^turing 
the state of an entity at given points in time. 

In accordance with methods consistent with the present invention, a method is provided 
10 in a data processing system. The method comprises the steps of creating a workflow that models 
a process and generating a plan from the workflow that represents an instance of the process. 

In accordance with methods consistent with the present invention^ a method is provided 
in a data processing system. The data processing system has a workflow that models a process. 
The method comprises the steps of generating a plan from the workflow that reflects an instance 
15 of the process and activating the plan to perform the instance of the process. 

In accordance with methods consistent with the present invention, a method is provided 
in a data processing system. The data processing system has a virtual file system server 
connected to a network storage mediimi. The method comprises the steps of using the virtual 
file system server to retrieve a workflow from the network storage medium, creating a plan from 
20 the workflow, and storing the plan on the network storage medium 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system 
comprises a virtual file system server connected to a network storage medium. The method 
25 comprises the steps of using the virtual file system server to retrieve an activity having a 
duration from the network storage medium, creating a task from the activity, and storing the task 
on the network storage medium. The step of creating the task comprises the steps of receiving 
an indication of a start time for the task, and setting an end time for the task equal to the duration 
after the start time. 

30 In accordance with articles of manufacture consistent with the present invention, a 

computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system 
comprises an activity with a duration. The method comprises the steps of creating a task from 
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the activity, and creating a different task from the activity. The step of creating the task 
comprises the steps of receiving an indication of a start time for the task, and setting an end time 
for the task equEil to the duration after the start time. The step of creating the different task 
comprises the steps of receiving an indication of a different start time for the task, and setting an 
5 end time for the task equal to the duration after the different start tkne. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perfomi a method. The data processing system 
comprises an activity with a duration. The method comprises the steps of creating a task from 

10 the activity, and creating a different task from the activity. The step of creating the task 
comprises the steps of receiving user input indicating a resource assigned to the task, receiving 
an indication of a start time for the task, and setting an end time for the task equal to the duration 
after the start time. The step of creating the different task comprises the steps pf receiving user 
input indicating a different resource assigned to the different task, receiving an indication of the 

15 start time for the task, and setting an end time for the different task equal to the duration after the 
start time. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system 

20 comprises a plurality of activities wherein each of the activities has a duration and wherein a 
predecessor one of the plurality of activities occurs before a successor one of the plurality of 
activities. The method comprises the steps of creating a predecessor task from the predecessor 
activity, and creating a successor task from the successor activity. The step of creating the 
predecessor task comprises the steps of receiving an indication of a start time for the predecessor 

25 task, and setting a predecessor end time for the predecessor task equal to the predecessor 
duration after the start time. The step of creating the successor task comprises the steps of 
setting a successor start time equal to the predecessor end time, and setting a successor end time 
equal to the successor duration after the successor start time. 

In accordance with articles of manufacture consistent with the present invention, a 

30 computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processiag system to perform a method. The data processing system 
comprises a plurality of activities wherein each of the activities has a duration and wherein one 
of the plurality of activities and another of the plurality of activities start and end at a same time. 
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The method comprises the steps of cre^tmg a task from the activity, and creeiting another task 
from the other activity. The step of creating the task comprises the steps of receiving an 
indication of a start time for the task, and setting an end time for the task equal to the duration 
after the start time. The step of creating the other task comprises the steps of setting another 
5 start time for the other task equal to the start time for the task, and setting another end time equal 
to the other duration after the start time. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The method comprises the steps 
10 of creating a workflow that models a process, and generating a plan from the workflow that 
represents an instance of the process. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable 'medixun is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system 
15 comprises a workflow that models a process. The method comprises the steps of generating a 
plan from the workflow that reflects an instance of the process, and activating the plan to 
perform the instance of the process. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
20 for controlling a data processing system to perform a method. The data processing system 
comprises a virtual file system server connected to a network storage medium. The method 
comprises the steps of using the virtual file system server to retrieve a workflow from the 
network storage medium, generating a plan from the workflow, and storing the plan on the 
network storage medium. 

25 Othex systems, methods, features and advantages of the present invention will be or will 

become apparent to one with skill ia the art upon examination of the following figures and 
detailed description. It is intended that all such additional systems, methods, features, and 
advantages be included within this description, be within the scope of the invention, and be 
protected by the accompanyiag claims. 
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Brief Description Of The Drawinp ;?; 

The accompanying drawings, which are incorporated in and constitute a part of this 
specification, illustrate an implementation of the present invention and, together with the 
description, serve to explain the advantages and principles of tiie invention. In the drawings: 

Fig. 1 depicts a data processing system suitable for practicing methods and systems 
consistent with the present invention; 

Fig. 2 dq)icts an architectural overview of the woikflow modeling and project planning 
integration tool used to p^form methods and systems consistent with the present invention; 

Fig. 3 depicts a flow diagram illustrating the high-level process perfomied by the tool of 
Fig. 2 in accordance with methods and systems consistent with the present invention; 

Fig. 4 depicts an exemplary document workflow modeled by an enterprise affiliate using 
the tool of Fig. 2; 

Fig. 5 depicts an exemplary task workflow modeled by an enterprise affiliate using the 
tool of Fig 2; 

Fig. 6 depicts another exemplary workflow modeled by an enterprise affiliate using the 
tool of Fig 2; 

Fig. 7 depicts a timeline of the task created firom the workflow of Fig. 4; 
Fig. 8 depicts a timeline of the task created from the workflow of Fig. 5; 
Fig. 9 depicts a timeline of the task created from the workflow of Fig. 6; 
Figs. 10-12 depict the execution of the plan depicted in Fig. 7; 
Figs. 13-16 depict the execution of the plan depicted in Fig. 8; 

Figs, 17-21 depict the execution of the plan depicted in Fig. 9 following the default path; 
Figs. 22-27 depict the execution of the plan depicted in Fig. 9 following the non-default 

path; 

Figs. 28A-C depict a flow diagram illustrating the creation or retrieval of a workflow by 
the tool of Fig. 2; 

Fig. 29 depicts an exemplary user interface of the tool of Fig. 2 used to begin creating or 
retrieving a workflow; 

Fig. 30 depicts an exemplary user interface of the tool of Fig. 2 used to enter the name of 
a new workflow group; 

- Fig. 31 depicts an exemplary user interface of the tool of Fig. 2 used to begin creating a 
new workflow; 
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Fig. 32 depicts an exemplary user interface of the tool of Fig. 2 used to enter the name of 
a new workflow; 

Fig. 33 A-C depict an exemplary workflow definition file produced by the tool of Fig. 2 
for the workflow depicted in Fig. 6; 

Fig. 34 depicts an exemplary user interface of the tool of Fig. 2 used to manage a 
workflow; 

Fig. 35 depicts an exemplary user interface of the tool of Fig. 2 used to add a new role to ' 
a workflow; 

Fig. 36 depicts an exemplary user interface of the tool of Fig. 2 used to select an artifact 

type; 

Fig. 37 depicts an exemplary user interface of the tool of Fig. 2 used to enter condition 
properties for a document-oriented artifact; 

Fig. 38 depicts an exemplary user interface of the tool of Fig.* 2 used to enter condition 
properties for a script-oriented artifact; 

Fig. 39 depicts an exemplary user interface of a script editor for the tool of Fig. 2; 

Fig. 40 depicts an exemplary user interface of die tool of Fig. 2 used to modify the 
properties of a workflow activity; 

Figs. 41 A and B depict a flow diagram illustrating the creation of a plan firom a 
workflow; 

Fig. 42 depicts an exemplary user interface of the tool of Fig. 2 used to create a new plan 

group; 

Fig. 43 depicts an exemplary user interface of the tool of Fig. 2 displaying the available 
plan groups; 

Fig, 44 depicts an exemplary user interface of the tool of Fig. 2 used to enter a plan 

name; 

Fig. 45 depicts an exemplary user interface of the tool of Fig. 2 used to enter the working 
schedule; 

Fig. 46 depicts an exemplary user interface of the tool of Fig. 2 used to enter the 
scheduled start and end times for the plan; 

Fig. 47 depicts an exemplary workflow definition file produced by the tool of Fig. 2 for 
the workflow of Fig. 5 is created; 

Fig. 48 depicts an exemplary plan definition file created firom the workflow definition 
file of Fig. 47; 



wo 02/19224 PCT/USOl/27177 

Fig. 49 depicts an exemplary user interface of the tool of Fig. 2 used to assign users to a 

plan; 

Fig. 50 depicts an exemplary user interface of the tool of Fig. 2 used to edit the 
properties of a plan; 

5 Fig. 51 depicts a timeline of the task created from the workflow of Fig. 5; 

Fig. 52 depicts an exemplary timeline of the tool of Fig. 2 used to activate a plan; 

Fig. 53 depicts a flow diagram illustrating the addition of a resource by the tool of Fig. 2; 

Fig. 54 depicts an exemplary user interface of the tool of Fig. 2 used to add a resource; 

Fig, 55 depicts an exemplary user interface of the tool of Fig. 2 used to receive LDAP 
10 access information; 

Fig. 56 depicts an exemplary resource file created by the tool of Fig. 2; 

Fig- 57 depicts a flow diagram illustrating the management of an activated plan; 

Fig. 58 depicts a timeline of the task created from the workflow of Fig. 5; 

Fig. 59 depicts an exemplary plan definition file created from the workflow of Fig. 5; 
15 Figs. 60, 62, 64 and 66 depict the actual timeline showing the execution of the plan 

depicted in Fig. 58; and 

Figs. 61, 63, and 65 depict the properties of the executing tasks of Figs. 62, 64, and 66. 



Detailed Description Of The Invention 

Methods and systems consistent with the present invention provide an integrated 

20 workflow modeling and project planning integration tool that improves the efficiency and 
reduces the operating cost of an enterprise or business conglomerate. Contrary to conventional 
tools that do not allow a user to integrate a workflow and a project plan, the integration tool 
allows a user to model a business process or workflow, to create and activate a project plan 
based on the workflow, and to track the progress of the activated project plan. The tool also 

25 allows the workflow to be reused to create more than one project plan based^on the workflow. 
The tool simultaneously manages the execution of the plans. Moreover, the integration tool may 
include a virtual file system server, such as a Web-based 'T)istributed Authoring and 
Versioning" (WebDAV) server that operates as a virtual file system for computers on a network. 
With the WebDAV server, more than one user on different computer systems may view the 

30 same workflow or project plan, monitor the progress of an activated project plan, or 
• simultaneously create and activate different plans from the same workflow. 



-8- 
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System Overview 

While methods and systems consistent with the present invention may apply to any 
enterprise in any industry, they will be further described below with reference to the software 
industry to provide clarity, consistency, and to demonstrate the invention as applied to one of the 
5 more difficult process industries. More particularly, methods and systems consistent with the 
present invention will be described with reference to a software development business process 
that is applicable to the software industry. 

Fig. 1 depicts a data processing system 100 suitable for practicing methods and systems 
consistent with the present invention. Data processing system 100 includes a group of 

10 computers 102a, 104, and 106 that are comected via a networic 108. Network 108 may be any 
known physical or wireless networic capable of sirpporting a data transmission between two 
computer systems, such as a Local Area Network (LAN), a Wide Area Network (WAN), the 
Internet, or leased phone lines. 

As further explained herein, computer 102a may actually be one of multiple computers 

15 (i.e., computers 102a and 102n) used by affiliates of an enterprise or business conglomerate to 
commimicate with one another via network 108. The enterprise affiliates may be employees, 
managers, administrators, suppliers, cxistomers, other computer applications, other computer 
systems, or other users within the enterprise who may need to create, view, or receive 
information regarding an* activated project plan in accordance with methods and systems 

20 consistent with the present invention. 

Each computer 102a, 104, and 106 includes a memory (110, 112, and II 4,. respectively), 
a secondary storage device (116, 118, and 120, respectively), an I/O device (122, 124, and 126, 
respectively), and a processor (128, 130, and 132, respectively). Memory 110 in computer 102a 
includes a Client Interface 134 to a .Web-based **Distributed Authoring and Versioning" 

25 (WebDAV) server 140 in memory 112. Client Interface 134 has Process and Plan modules 136 
that collectively allow an enterprise affiliate to create a reusable workflow and to create and 
activate a project plan based on the reusable workflow. 

Memory 110 in computer '102a also includes a target processor interpreter, such as a 
Java™ Virtual Machine 138. To permit the Client Interface 134 to run on most any computer, 

30 the Client Interface 134 may be developed using the Java^w Programming Language. Thus, 
Client Interface 134 may include Java™ bytecodes. The Java™ Virtual Machine 138 interprets 
the Java™ bytecodes of the Client Interface 134 so that the Client Interface 134 may execute on 
computer 102a, 
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The WebDAV server 140 in memory 112 of computer 104 operates as a virtual file 
system for computers 102a, 102n, and 106 on the network 108. To operate as a virtual file 
system, WebDAV Server 140 communicates on the network 108 using the WebDAV protocol, 
and stores files on WebDAV storage 142. In one implementation, WebDAV storage 142 may 
5 be a known database, such as Oracle, DB2, MS Structured Query Language (SQL) storage, or 
any Java Database Connectivity (JDBC)-compliant database. In this implementation, WebDAV 
Server 140 includes a database management system (DBMS) or a JDBC interface to control 
access to the WebDAV storage 142. 

In accordance with methods and systems consistent with the present invention, two 

ID sqparate enterprise affiliates using their respective Ghent Interfaces 134 on their respective 
computers 102a and 102n may independently request and view the same workflow or plan 
stored on WebDAV Storage 142. In addition, the Ghent Interface 134 allows any enterprise 
affiliate to create, delete, move,' and. copy workflows, project plans, and associated 
roles/resource lists on WebDAV server 140. Furthermore, properties of a process, a plan, or a 

15 task of a plan may be added, located, or changed on WebDAV Storage 142 by Client Interface 
134 using known methods of the WebDAV protocol. 

The WebDAV protocol is a set of known extensions to the standard HyperText Transfer 
protocol (HTTP) that allows enterprise afBHates using cUent computers 102a and 102n to 
collaboratively store, edit, and manage files remotely on a Web Server, such as WebDAV Server 

20 140 using network 108. As known to one skilled in the art, HTTP defines how messages sent to 
or fi-om a Web server on the Internet are formatted and transmitted. HTTP also defines what 
actions a Web server or Web browser of a computer on the Internet should take in response to 
various commands submitted as part of an HTTP message. 

The WebDAV protocol, defines a WebDAV resource to be a collection (e.g., a directory 

25 or folder on WebDAV Storage 142) or a collection member (e.g., a file or Web page on 
WebDAV Storage 142). Each WebDAV resource has a content file and properties associated 
with the content file. The properties include the creation date, the author, and the access rights 
for the WebDAV resource. The WebDAV protocol specifies the methods to create, delete, 
move, and copy a WebDAV resource. It also specifies the methods to add, find, or change a 

30 property of a WebDAV resource. The WebDAV protocol and the HTTP extensions that 
comprise the WebDAV protocol are more clearly described in the followiag reference, which is 
incorporated herein by reference: HTTP Extensions For Distributed Authoring — WebDAV, 
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RFC 25 18, Standards Track, Proposed Standard, February 1 999, available at 
http://andrew2.aiidrew.cmu.edu/rfc/rfc25 1 8.html. 

Memory 114 in computer 106 includes a Tool Server 144, The Tool Server 144 includes 
a WebDAV proxy 146 and Management Modules 148. WebDAV proxy 146 mediates 
5 communication between the Client Interface 134 and the WebDAV server 140. The messages 
or requests directed to the WebDAV server 140 from the Client Interface 134 are initially sent to 
the WebDAV proxy 146, as discussed in detail below. The WebDAV proxy 146 passes these 
messages and requests to the Management Modules 148. Each of the Management Modules 148 
is configured to inform the WebDAV proxy 146 when a message or request has been serviced. 
10 If none of the Management Modules 148 services the message or request, then the WebDAV 
proxy 146 sends the message or request to the WebDAV Server 140 via the network- 108. If, on 
the other hand, the Management Modules 148 are able to service the message or request, the 
message or request is not sent to the WebDAV Server 140. The types of messages or- requests 
serviced by the Management Modules 148 include activating a project plan, notifying various 
15 enterprise affiUates assigned to each task of the plan, and managing the execution of the plan to 
the enterprise aflSIiates. 

In another' implementation, memory 114 in computer 106 mcludes a WebDAV servlet 
(not shown), which is an application designed to perform as a WebDAV Engine in heu of 
WebDAV Server 140. The WebDAV servlet may be started by and executed within the Tool 
20 Server 144. In this implementation, WebDAV servlet is persistent. Thus, once WebDAV 
servlet is started, it stays in memory and can fulfill multiple requests. WebDAV servlet is 
configured to control access to WebDAV Storage 142, which may be included in secondary 
storage 120 in computer 106. 

Memory 114 in computer 106 also includes, a target processor interpreter, such as a 
25 Java™ Virtual Machine 150. As with the Client Interface 134 on computer 102a, the Tool 
Server 144 includes Java™ byteoodes that the Java Virtual Machine 150 interprets so tiiat the 
Tool Server 144 may execute on computer 106, 

In another implementation, the data processing system 100 may operate in a local host 
configuration rather than across the network 108. In this implementation, the memory 110 of 
30 computer 102a may include the Tool Server 144 and the WebDAV Server 140, In addition, the 
secondary storage device 116 may include the WebDAV Storage 142. 

Although aspects of the present invention are described as being stored in memory, one 
skilled in the art will appreciate that these aspects can also be stored on or read from other types 
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of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or 
CD-ROM; a carrier wave firom a network, such as Intemet; or other forms of RAM or ROM. 

Fig. 2 depicts a functional architectural overview of the workflow modeling and project 
planning integration tool 200 used to integrate workflow modeling and project planning. As 
5 shown m Fig. 2, the tool 200 includes the Client Interface 134 as well as the Tool Server 144. 
Although part of the same tool 200, the Ghent Interface 134 and the Tool Server 144 may be 
located on different computer systems, as discussed above. 

The Chent Interface 134 includes a Virtual File System C*VFS*') Interface 202 that is 
configured to allow the Chent Interface 134 to connect to the secondary storage device 116 for 

10 local file access or to connect to the WebDAV Storage 142 via the WebDAV proxy 146 for 
virtual fiJe access. To allow the WebDAV proxy 146 to mediate commxanication between the 
Client Interface 134 and the WebDAV Storage 142, the VFS Interface 202 is configured to send 
the virtual file access requests fi-om the Client Interface 134 to a Uniform Resource Locator 
(URL) or network address for the WebDAV proxy 146. For example, the URL for the 

15 WebDAV proxy 146 may be *'http://www.ToolServer.comAVebDAVproxy.'* A URL typically 
consists of an access protocol (e.g., http\ a domain name (e.g., www.ToolServer.com), and, 
optionally, the path to a file or resource residing on that server (e.g., WebDA Vproxy). If the Tool 
Server 144, where the WebDAV proxy 146 is located, has an IP address of 192.168.5.1 and an 
assigned port address of 8088, then the URL for the WebDAV proxy translates to 

20 'littp://192.168.5.1:8088AVebDAVproxy." 

As discussed above, the VFS Interface 202 initially sends the requests that the Client 
Interface 134 directs to the WebDAV Storage 142 to the WebDAV proxy 146. The WebDAV 
proxy 146 sends these requests to the Management Modxxles 148. Aiter the Management 
Modules 148 review these requests, the WebDAV proxy 146 sends the request to the WebDAV 

25 server 140 if the Management Modules 148 do not respond to the requests from the Chent 
Interface 134. If the request is to be sOTt to the WebDAV server 140, the Tool Server 144 
directs the request to a URL or network address for the WebDAV server 140. 

The Chent Interface 134 also includes a module loader 204 to load the Process and Plan 
modules 136. As one skilled in the art will appreciate, Chent Interface 134 may be developed so 

30 that the functionality provided by Process and Plan modules 136 is not loaded by a known 
module loader 204, but integrally incorporated within the element correspondmg to the Chent 
Interface 134. The Process and Plan modules 136 produce the requests to store or modify the 
various chent files on the WebDAV storage 142. As further described below, the various types 
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of client files include a condition model, a user profile, a resource profile, a'workflow definition 
file, and a plan definition file. Each of these files has properties defined va accordance with the 
WebDAV protocol. The various types of client files follow a schema or document type 
definition that is known to the Tool Server 144 so that the Tool Server 144 can identify the type 
5 of client file sent by the Client Interface 134 and intercepted by the WebDAV Proxy 146. In 
addition, each type of client file has a unique identifier, such as a URL network address, which 
the Tool Server 144 may use to locate the associated cUent file for processing. The various 
types of client files are discussed in context with the general description of the Process and Plan 
modules 136 and also further discussed with the implementation details of creating a workflow 

10 and a project plan fix>m the woiicflow. Although XML files are used to represent the client files 
used with methods and systems consistent with the present invention, one skilled in the art will 
recognize that any file type can be used to represent the client files. 

The Process and Plan Modules 136 include a Resource Manager Module 206, an 
Activity I/O Condition Designer Module 208, a Process Designer Module 210, a Project Plan 

15 Manager Module 212, and a Task Tracker Module 214. The Resource Manager Module 206 
allows an enterprise affiliate with system administrative privileges or permissions, such as a 
project manager, to create, modify, and store a user profile for an enterprise affiliate. The user 
profile identifies the access control rights that are associated with the enterprise affiUate, such as 
whether the enterprise affiliate may create or edit or delete a project plan based on a workflow or 

20 whether the enterprise affiliate is limited to viewing an existing workflow or plan. When the 
Client Interfece 134 sends a request to tiie WebDAV Server 140 to store the user profile, the 
Client Interface 134 may specify that the user profile be stored with a unique identifier so that 
the Tool Server 144 may later locate the user profile for further processing. For example, the 
Client Interface 134. may request that the unique identifier be a location or URL where the user 

25 profile is to be stored on tiie WebDAV Storage 142. If the unique identifier is stored as a 
property of the user profile on the WebDAV storage 142, the Client Interface 134 sends a 
request to the WebDAV Server 140 to set the value of the property. 

The Resource Manager Module 206 also allows an enterprise affiliate to create, modify, 
and store the role profiles that may be assigned to an activity of a workflow that is modeled 

30 using the tool 200. The role profile identifies a group of resources that may be assigned to 
complete a task created firom the activity. The role profile is a type of client file that the Client 
Interface 134 may store on WebDAV storage 142 with a unique identifier (e.g., a URL for the 
role profile) to locate the role profile at a later time. A role profile may include a Rolename that 
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represents a "capability'* or "skill set" for the role. For example, xxsing methods and systems 
consistent with the present invention, an enterprise afSliate may identify one of the following 
Rolenames to the Resource Manager Module 206 so that the associated role profiles are later 
available to assign when defining a software development process: Manager, Analyst, Software 
5 Architect, Software Developer, Tester, Hardware Architect, and Editor, 

In addition to the above, the Resource Manager Module 206 fiorther allows an enterprise 
affiliate to create, modify, and store the resource profiles (e.g., the person, equipment, or 
systems, such as a development faciUty) that may be assigned to a task of a plan created from a 
workflow. The resource profile includes a resource ID and a unique identifier for the role 

10 profile so that the Client Interface 134 may communicate to the Tool Server 144 that the 
identified resource has skills or capabilities corresponding to the role profile. For example, 
when the resource is a person, the Tool Server 144 may recognize that the person can play a 
given role (e.g.. Analyst) in a specific activity (e.g., Requirements Analysis) in a workflow (e.g.. 
Software Development Process) based on the skills or capabilities required by the role assigned 

15 to the activity to be performed. 

The Activity I/O Condition Designer Module 208 allows an enterprise affiliate, such as a 
manager, to define a condition model, i.e., an input condition or an output condition, for an 
activity of a workflow. The Activity I/O Condition Designer Module 208 stores the condition 
model with a xmique identifier so that the Tool Server 144 may later locate the condition niodel 

20 for processing, such as when a task of a plan is created firom the activity of the workflow, as 
explained below. 

As discussed above, there are two types of workflows: a document workflow and a task 
workflow. Similarly, there are two types of conditions: a document-type condition and a logic- 
type condition. The Activity I/O Condition Designer Module 208 allows the enterprise affiliate 
25 to create a condition model based on one of these two condition types. The Activity I/O 
Condition Designer Module 208 also allows the enterprise affiliate to assign a document-type 
condition model or a logic-type condition model to an activity when creating the activity in a 
workflow. Each docxoment-type and logic-type condition model has properties defined by the 
enterprise affiliate that created the respective condition model using the Activity I/O Condition 
30 Designer Modxde 208. 

The properties of the docimient-type condition model include a location property (e,g., a 
URL) identifying the location of the document or artifact being monitored. Thus, when 
executing a task based on an activity, the Client Interface 134 uses the location property to 
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notify, the resource responsible for the task where to find the document or artifact so that the 
resource may complete its task. 

Another property of the document- type condition model is a state property that indicates 
the allowable states of the document or artifact For example, the document may have the states 
5 *T)RAFT" and "APPROVED." When creating the workflow, the enterprise af&liate assigns one 
of these allowable states as a condition for entry into or exit firom the activity (or the task created 
fix>m the activity). When the task is activated, the Workflow Engine 222 evaluates whether the 
state property of the document condition satisfies the input or output condition of the activated 
task before starting or closing the task. 
10 When creating a logic-type condition model. Activity I/O Condition Designer Module 

208 allows the enterprise af&liate to define the properties shown in Table 1. ' 
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TABLE 1 



Property 


Description 


Name 


The name used to identify the condition. 


Description 


A description of the condition. 


When to 
Check 


This section identifies when and/or how * 
often the condition should be checked. 


• Abs. Time 


The condition is checked when this 
absolute time (calendar time) arrives. 


• Period 


Liteger expression in Javascript that 
defines the periodicity of condition check, 
where a "1" me^s once a minute. (If 
absolute time is also specified, then the 
condition should be checked when tiie 
absolute time arrives and periodically 
thereafter.) 


•URL 

Change 


The condition is checked after URL . . 
undergoes a property or content change. 


• Task 
Change 


The condition is checked when the task 
that is specified during plan creation 
changes its state {e,g,, starts, finishes). 


•Any 

Request 


The condition is checked when any HTTP 
request is detected. 


Script 


The script to run when the condition is 
met. The script must retum "true" or 
"false" (a Boolean). Script is an 
extensible method for users to enter in ad 
hoc logic. 



When a plan is created firom a workflow, the Client Interface 134 uses the logic-type 
condition model to generate a logic-type condition for entry/exit and the script (e.g., logic 
element) to be perfomied to detemiine if the condition is met. For example, the enterprise 
5 affiliate may indicate to ttie Activity I/O Condition Designer Module 208 that the condition is to 
check if the task is complete and that the logic to be performed is to check the status property of 
the task. In this case, the user or resource assigned to this task must notify the Client Interface 
134 that the task is complete. In another example, the enterprise affiUate may indicate to the 
Activity I/O Condition Designer Module 208 that the condition is to check if the task is 
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complete and that the logic to be performed is to check for the existence of a file in a specific 
directory folder on WebDAV Storage 142 in order to determine if the task is complete. In this 
case, the user or resource assigned to this task must create or move a file into the specific 
directory folder to indicate that the task is complete. 
5 The Process Designer Module 210 allows an enterprise affiliate to create, modify, and 

store a workflow. When the enteiprise affiliate indicates to Process Designer Module 210 that 
the modeled process is to be saved. Process Designer Module 210 produces a workflow 
definition file based on the modeled workflow object. Client Interface 134 then sends as the 
workflow definition file as a cUent file to WebDAV Server 140 to be stored on WebDAV 
10 Storage 142. Each workflow definition file produced by Process Designer Module 210 includes 
a unique identifier (e.g., a URL for the workflow definition file) so that Tool Server 144 may 
later locate the workflow definition file corresponding to the modeled workflow for finlher 
processing. 

Project Plan Manager Module 212 allows an enterprise affiliate to create and activate a " 

15 project plan from a workflow definition file. In general, upon request to create a project plan. 
Project Plan Manager Module 212 sends a query message to the WebDAV Server 140 for the 
workflow definition files contained in WebDAV Storage 142. As fiirther described below. 
Project Plan Manager Module 212 receives the workflow definition files, allows the enterprise 
afiSliate to select one of the workflow definition files to create a project plan, and then produces 

20 a plan definition file based on the selected workflow definition file. When instructed to save the 
plan by the enterprise affiliate. Project Plan Manager Module 212 sends the plan definition file 
as a cUent file to WebDAV Server 140 to be stored on WebDAV Storage 142. Each plan 
definition file produced by Process Designer Module 210 includes a unique identifier (e.g., a 
URL for .the plan definition file) so that Tool Server 144 may later tocate the workflow 

25 definition file corresponding to the modeled workflow for fiirther processing. 

The Task Tracker Module 214 allows an enterprise affiliate to view the tasks of an 
activated project plan that are assigned to a specific resource, to activate or start a task of the 
project plan (e.g., indicate actual start time to Client Interface 134), to open or check-out a 
document artifact needed to accomplish the task, to close or check-in the docunient artifact after 

30 accomplishing the task, and to indicate that the task is completed. 

The Tool Server 144 includes a module loader 216 to load the Management Modules 
148.. Similar to the Client Interface 134, the Tool Server 144 inay be developed so that the 
fiinctionality provided by Management Modules 148 is not loaded by a known module loader 
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216, but integrally incorporated within the element corresponding to the Tool Server 144. 
Management Modules 148 include a User Authorization Module 218, a Resource/Role 
Management Module 220, and a Workflow Engine 222. The Workflow Engine 222 includes a 
Project Plan Management Module 224 and a Project Task Management Module 226. 
5 ■ When the Client Interface 134 requests access to a client file on the WebDAV Storage 

142, the User Authorization Module 218 verifies that that the enterprise affiliate making the 
request has a user profile on the WebDAV Storage 142 with the proper authorization or 
permission to access the requested client file. The User Authorization Module 218 may be 
connected to a Light Directory Access Protocol (IX>AP) Import Modide 228, which follows a 

10 known LDAP protocol to allow the User Authorization Module 218 to obtain existing user 
profiles from another computer on network 108. As known to those skilled in the art, an LDAP 
protocol is based on "entries," where an entry is a collection of attributes that have a 
"distinguished name" (DN). According to the LDAP protocol, directory entries are arranged in 
a hierarchical tree-like structure that reflects political, geographic, and/or organizational 

15 boundaries. For example, entries representing covmtries may appear at the top of the tree. The 
entries below the covmtries may represent states or national organizations. Below the states or 
national organizations may be entries representing people (e.g., user profiles), organizatioiial 
units, printers, documents, or any other accessible entity. Each level in the hierarchical tree-like 
structure for the directory entries may be identified by a known standardized keyword, such as 

20 "CN" for the common name of the entry (e.g., user profile), "L" for locality name, "ST" for state 
or province name, "O" for organization name, "OLP' for organizational xmit name, and "C" for 
country name. The LDAP Import Module 228 uses a DN to refer to the entry unambiguously 
via a concatenation of the hierarchical tree-like structure. After user profiles are retrieved by the 
User Authorization Module 218 via the LDAP import module 228, the user profiles may then be 

25 stored on the WebDAV Storage 142 by a request from the Ghent Interface 134; 

The Resource/Role Management Module 220 reviews requests from an enterprise 
af&Uate to assign a resoxurce to a plan (e.g., to assign a user to a task of the plan). The 
Resource/Role Management Module 220 may check the resource profile corresponding to the 
assigned resource on the WebDAV Storage 142 to verify that the resource is not overloaded. 

30 For example, the Resource/Role Management Module 220 determines whether a resource is 
already assigned to another task in another plan during the same time frame, thus preventing it 
from being able to complete one of the tasks to which it is assigned. The Resource/Role 
Maaagement Module 220 may also be connected to the LDAP Import Module 228 to allow the 
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Resource/Role Management Module 220 to obtain existing resource profiles firom another 
computer on network 108. The resource profiles may also be stored on WebDAV Storage 142 
by a request firom Client Interface 134. 

The Workflow Engine 222 reviews requests to activate, deactivate, or update a plan. For 
5 example, a request to update a plan occurs if the enterprise affiliate who is an owner of a task 
indicates in its request that the task is complete. The Workflow Engine 222 also manages the 
execution of the activated plans. 



ffi gh-Level Process 

Fig. 3 depicts a flow diagram illustrating the high-level process performed by the 

10 workflow modeling and project planning iategration tool ia accordance with methods and 
systems consistent with the present invention. Initially, the tool creates or retrieves a workflow 
(step 302). The tool then displays the workflow (step 304). The workflow comprises a set of 
activities that represents the steps to be performed as part of a plan executed Scorn the workflow. 
Each activity has an activity description and at least one role responsible for the activity. The 

1 5 activity description indicates what step is to be performed by the role. 

There are two types of workflows: a document workflow and a task workflow. In a 
document workflow, the state of one document (or, more generally, any item or artifact) is 
monitored by the activities of the workflow. . Thus, a document workflow cannot usually have 
parallel activities, which would require the parallel activities to monitor the states of more than 

20 one artifact or would require the parallel activities to monitor different states of the same artifact 
simultaneously. The document is in one state at a time. Fig. 4 depicts an exemplary docimient 
workflow 400. " As shown, the workflow 400 iQcludes a start element 402, an end element 404, 
and two activities, "Step 1" 406 and "Step 2'* 408. Because "Step 1" 406 occurs directly before 
"Stq> 2" 408, "Step 1" 406 is the ^'predecessor activity" to "Step 2" 408. Similarly, "Step 2" 

25 408 is the "successor activity" to "Step 1" 406. The workflow 400 is used to monitor the state 
of Artifact 410. In particular, in "Step 1" 406, the state of Artifact 410 is "State 1" 412, in "Step 
2" 408, the state of Artifact 410 is "State 2" 414, and at the end 404 of the workflow, the state of 
Artifact 410 is "Complete" 416. 

A task workflow, on the other hand, typically has no limitations regarding the nvimber of 

30 artifacts that may be monitored or modified by each activity of the workflow to achieve or 
contribute to the business process goal, such as an auditing process that determines if multiple 
' accounts are balanced properly. Fig. 5 dqpicts an exemplary task workflow 500. The task 
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workflow 500 includes a start element '502, an end element 504, two serial activities 506 and 
508 and two parallel activities 510 and 512. The workflow also includes two synch bars 514 
and 516, which are used to connect the ends of parallel activities. Contrary to the document 
workflow, the task workflow allows for parallel activities. 
5 Another exemplary workflow 600 is depicted in Fig. 6. The workflow 600 includes a 

start element 602 and an end element 604. The &st activity of the workflow 600 is "Get Parts" 
606, which is followed by a logic activity, 'TL or Rt Handed?" 608. Logic activities have two 
successor activities: a "default activity" and a "non-default activity." As the name impUes, the 
workflow generally follows the path of the default activity imless a condition is met in the logic 

10 activity, as discussed in detail below. In Fig. 6, the default activity is "Righf 610. The non- 
default activity is "Left" 612, which is followed by another activity *T,eft Special" 614. The 
default path is represented as a solid connector 616 while the non-default path is represented as a 
dotted comiector 618. One skilled in the art, however, will recognize that any visible difference 
in the connectors, e.g., a change in type, color, shading, labeling, etc., may be used to represent 

15 both the default path as well as the non-default path. Both the default activity 610 and the non- 
default activities 612 and 614 are followed by another activity, "Complete Assembly" 620. In 
addition, though we show only two paths (616 & 618) out of the decision block 608, there could 
be any number of exit paths (not shown). 

Returning to Fig. 3, the next step performed by the tool is to create a plan from the 

20 workflow (step 306). Each activity in the default path of the workflow generally corresponds to 
a task in the plan. The task identifies the schedided start and stop tunes for the task. The tool 
then displays the plan (step 308). For example, the plan created from the workflow 400 depicted 
in Fig, 4 is shown in Fig. 7. The plan 700 includes two tasks 702 and 704 that correspond to the 
two activities 406 and 408 from the workflow 400. The first task 702 is scheduled to begin at 9 

25 a.m. 706 on August 1, 2001 (not shown), and end at 6 p.m. 708 on the same day. The second 
task 704 is scheduled to begin at 9 a.m. 710 on August 2, 2001 (712) and end at 5 p.m. 714 on 
the same day. 

• The plan 800 created from the workflow 500 depicted in Fig. 5 is shown in Fig. 8. The 
plan 800 includes two serial tasks 802 and 804 that correspond to the two serial activities 506 
30 and 508 from the workflow 500. The plan 800 also includes two parallel tasks 806 and 808 that 
correspond to the two parallel activities 510 and 512 from the workflow 500. As shown in Fig. 
8, "Serial 1" task 802 is scheduled to begin at 9 a.m. 810 on August 1, 2001 (812) and end at 
5:30 p.m. 814 on the same day. The parallel tasks 806 and 808 are scheduled to start at the 
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completion of the "Serial 1" task 802, and are scheduled to end at 6 p.ni. 816 on August 2, 2001 
(818). The "Serial 2" task 804 is scheduled to begin upon completion of the parallel tasks 806 
and 808 and is scheduled to end at 6 p.m. 820 on August 3, 2001 (822). 

The plan 900 created from the workflow 600 depicted in Fig. 6 is shown in Fig. 9. The 

5 plan 900 includes a task 902 corresponding to the activity "Get Parts" 606, followed by a task 
904 corresponding to the activity 'X or Rt Handed?" 608. The following task 906 corresponds 
to the activity "Right" 610. The final task 908 conresponds to the activity "Complete Assembly" 
620. The plan 900 depicts the default padi, and does not include any of the tasks corresponding 
to the non-default path. Althougji the start and end times are not depicted in the plan 900 shown 

10 in Fig. 9, each task has a scheduled start and stop time. In addition, the tool 200 requires that an 
enterprise affiliate assign a resource to each task, as described below. 

Returning to the high-level process of Fig. 3, the tool then activates the plan (step 310). 
Next, the tool manages the execution of the activated plan (step 312). The tool also modifies the 
display of the plan as each task is executed (step 314). The tool then determines whether the 

15 execution of the plan is complete (step 316). If the execution of the plan is complete, processiag 
ends. Otherwise, processing continues to step 312. 

For the exemplary plan .700 depicted in Fig. 7, upon activation, the first task 702 begins 
. execution. The tool depicts the executing task 1002 by darkening the outer borders of the block 
representing the task 1002, as depicted in the plan 1000 shown in Fig. 10. After completion of 

20 the task, the tool depicts the executed task 1 102 as a darkened block in the plan 1 100, as shown 
in Fig. 11. At this point, the second task 1104 begins execution, as indicated by the darkened 
outer borders of the task 1104. Finally, after both tasks 1102 and 1104 of the plan 1100 have 
been executed, both tasks 1202 and 1204 are depicted as darkened blocks in the plan 1200, as 
shown in Fig. 12. In this embodiment, the tool r^resents an executing task with darkened 

25 borders and represents an executed task as a darkened block. One skilled in the art, however, 
will recognize that any visible change in the blocks representing the tasks, e.g., a change in 
shape, color, shading, labeling, etc., may be used to represent the tasks in their various states. 
For example, in another implementation, color may be used to indicate active tasks; for example 
a gray rectangle may be used behind the task to indicate an actual activity since the actual dates 

30 may not coincide with the dates of the plaimed task. Thus, the representation of the tasks used 
■ in the methods, systems, and articles of manufacture consistent with the present invention are 
not limited to those used in the present embodiment. 
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The activation and execution of the tasks of the plan 800 depicted in Fig. 8 are shown in 
Figs. 13-16. Fig. 13 depicts the state of the plan 1300 while the "Serial 1" task 1302 is 
executing. Fig.-M depicts the state of the plan 1400 after execution of the "Serial 1" task 1402, 
while the "Parallel 1" and the 'Tarallel 2" tasks 1404 and 1406 are executing. Fig. 15 depicts 
5 the state of the plan 1500 after execution of the "Serial r* task 1502 and the "Parallel 1" and the 
'TaraUel 2" tasks 1504 and 1506, while the "Serial 2" task 1508 is executing. FinaUy, Fig. 16 
depicts tibe state of the plan 1600 after execution of the tasks 1602, 1604, 1606, and 1608. 

As discussed above. Fig. 9 represents a plan 900 created from a workflow 600 having a 
logic block 608. The activation and execution of the tasks of the plan 900 following the default 
10 path are shovm in Figs. 17-21, while the activation and execution of the tasks of the plan 900 
following the non-default path are shown in Figs. 22-27. 

Fig. 17 depicts the state of the plan 1700 while the "Get Parts*' task 1702 is executing. 
Fig. 18 depicts the state of the plan 1800 after the execution of the "Get Parts** task 1802, while 
the '*L Or Rt Handed?" logic task 1804 is executing. The logic task may pop up a dialog (not 
15 shown) to prompt the resource assigned to this task to provide an answer for this "left or right- 
handed'* question. In addition, the tool allows the question to be "answered** by running a logic 
script. This script may examine properties of an indicated artifact or it may execute a separate 
program on a separate system to compute the answer. Upon selection of the default path, the 
. plan 1900 shown in Fig. 19 depicts both the "Get Parts" task 1902 and the Or Rt Handed?" 
20 logic task 1904. in executed states, while the "Right" task 1906 is depicted in an executing state. 
After the execution of the "Right" task 1906 is complete, the state of the plan 2000 is depicted in 
Fig. 20 with the "Get Parts'* task 2002, the 'TL Or Rt Handed?** logic task 2004, and the *Tlight'* 
task 2006 in executed states and v^th the "Complete Assembly** task 2008 in an executing state. 
Finally,' upon completion of the "Complete Assembly" task 2008, the state of the plan 2100 after 
25 execution of the tasks 2102, 2104, 2106, and 2108 is complete is depicted in Fig. 21. 

Alternatively, if the non-default path is to be chosen, the execution of the plan is initially 
the same as when the defaidt path is chosen. Thus, as depicted in Fig. 22, the plan 2200 begins 
with the execution of the "Get Parts" task 2202. After completion of the "Get Parts" task 2202, 
the plan 2300 shown in Fig. 23 depicts the "Get Parts" task 2302 in an executed state while the 
30 "L Or Rt Handed?" task 2304 is shown in an executing state. At this point, the resource 
assigned to choose the default or the non-default path chooses the non-default path, thus 
completing the execution of the *X Or Rt Handed?" task 2404, as indicated in Fig. 24. Upon 
selection of the non-default path, the tool 200 modifies the plan 2400 to correspond to the non- 
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default path of the corresponding workflow. The plan 2400 depicts the tasks included in the 
non-default path. Thus, the plan 2400 includes the 'Xeft*' and "Left Special" tasks 2406 and 
2408 rather than the "Right" task 2306, which is depicted in Fig. 23 before the non-default path 
was chosen. As shown in Fig. 24, the 'Teft" task 2406 is executing. Fig. 25 depicts the plan 
5 2500 after the "Get Parts" task 2502, the **L Or Rt Handed?" logic task 2504, and the "Left" task 
2506 have been executed, while the '*Left Special" task 2508 is executing. Continuing with the 
execution of the plan. Fig. 26 depicts the state of the plan 2600 after the "Get Parts" task 2602, 
the ^TL Or Rt Handed?" logic task 2604, the *T.eft" task 2606, and the 'TLeft Special" task 2608 
are done executing, while the "Complete Assembly" task 2610 is executing. Finally, Fig. 27 
10 depicts the state of the plan 2700 after completion of the tasks 2702, 2704, 2706, 2708, and 
2710. 

Retrieving Or Creating A Workflow 

Figs. 28A-C depict a flow diagram illustrating an exemplary process for retrieving or 
creating a workflow, i.e., step 302 in Fig. 3. Initially, the tool 200 determines whether to use an 

15 existing process or workflow group (step 2802). A workflow group is a collection of workflows 
(e.g., a directory or folder containing the collection of workflows) created by the Client Interface 
134 on WebDAV Storage 142. Each workflow group is created by the Client Interface 134 on' 
WebDAV Storage 142 with the "workflow group" property as explained further below. When 
creating a workflow, the Ghent Interface 134 allows the enterprise affiliate to store the workflow 

20 within an identified workflow group so that any enterprise aflSliate using the Client Interface 
134 is able to easily identify related workflows using a hierarchical relationship. For example, 
software-related workflows may be stored within the same workflow group so that an enterprise 
affiliate is able to quickly locate a desired workflow in order to create a corresponding plan 
using the Client Interface 134, One skilled in the art will appreciate that Client Interface 134 

25 may store a workflow on WebDAV Storage 142 without associating the workflow with a 
workflow group. 

The tool 200 receives user input fi?om an enterprise affiUate with system administrative 
privileges or permissions, such as a process designer or a project manager, to determine whether 
to retrieve an existing workflow group or to create a new workflow group. If the tool 200 
30 detemiines that it will use an existing workflow group, the tool 200 receives an identification of 
the workflow group from the enterprise affiliate (st^ 2804). In one implementation, the Client 
Interface 134 may retrieve the identifications for the workflow groups on the WebDAV Storage 
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142 by requesting that the folders or directories on WebDAV Storage 142 having a "workflow'' 
property be returned by the WebDAV Server 140. The Client Interface may use any known 
method in accordance with WebDAV protocol to request that the WebDAV Server 140 retum 
any directory or folder on WebDAV Storage 142 that corresponds to a workflow group. The 
tool 200 may then display the available workflow groups to allow the enterprise af&liate to 
select one of the available workflow groups. For example, as shown on the user interface 2900 
depicted in Fig. 29, the tool 200 may display a hierarchical view 2902 of an identified workflow 
group 2904 stored on the root directory 2906 of WebDAV Storage 142. Alternatively, the 
enterprise affiliate may enter the identification of the desired workflow group to the tool 200 for 
retrieval. Using the identification, the tool 200 then retrieves the workflow group (step 2806). 

If the tool 200 determines that a new workflow group will be created, the tool 200 
receives the name of the workflow group from the enterprise affiliate (step 2808). For example, 
the enterprise af&liate may request a new workflow group by clicking on *Trocess Designer" 
button 2908 of the user interface 2900 depicted in Fig. 29. The enteiprise afQUate may, 
alternatively, use any known data input technique, such as an icon or keyboard input, to indicate 
. the request to the tool 200. Upon selecting the '^Process Designer"' button 2908, tiie tool 200 
displays an exemplary user interface 3000 depicted in Fig. 30 for receiving a new workflow 
group identification 3002 via keyboard input from an enterprise affiliate using computer 102a or 
102n. 

After receiving the new workflow group identification, the tool 200 creates a new 
workflow group in storage (step 2810). For example; the. tool 200 may create the workflow 
group on WebDAV Storage 142. To generate a new workflow group on WebDAV Storage 142, 
the Client Interface 134 sends the WebDAV Server 140 a request to create a new collection or 
folder on WebDAV Storage 142 with the same identification as the new workflow group 
identification 3002. In accordance with WebDAV protocol, the Client Interface 134 receives a 
response from' the WebDAV Server 140 confirming that the new workflow group folder was 
created on WebDAV Storage 142. As previously discussed, when a new collection or folder is 
created using the WebDAV protocol, the WebDAV properties (e.g., "date of creation," 
'^property name" and "lockdiscovery" properties) are created and stored in association with the 
new directory by the WebDAV Server 140. Thus, when generating the new workflow group, 
the Client Interface 134 also sets the '"property name" of the new workflow group to be 
"workflow group" so that the Client Interface may subsequently use known WebDAV methods. 
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such as 'TropFind," to retrieve the identification of each workflow group on WebDAV Storage 
142. 

After retrieving an existing workflow group or creating a new workflow group, the tool 
200 determines whether to use an existing workflow (step 2812). The tool 200 receives user 
5 input firom an enterprise affiliate with appropriate privileges or permissions to determine 
whether to retrieve an existing workflow or to create a new workflow. If the tool 200 
determines that it will use an existing workflow, the tool 200 receives an identification of the 
workflow from the enterprise affiliate (step 2814). In one implementation, the Client Interface 
134 may retrieve the identifications for the workflows in the selected workflow group and 
10 display the available workflows to allow the enterprise affihate to select one of the available 
workflows. Altematively, the enterprise affiliate may enter the identification of the desired 
workflow to the toot 200 for retrieval. Using the identification, the tool 200 then retrieves the 
workflow (step 2816). 

If the tool 200 determines that a new workflow will be created, the tool 200 receives Uxo 

15 name of the workflow from the enterprise affiliate (step 2818). For example, the enterprise 
affihate may request a new workflow by clicking on the desired workflow group 3102 and 
selecting the **New Process" option 3104 from a pxdl-down menu 3106 on the user interface 
3100 depicted in Fig. 31. The enterprise affiliate may, altematively, use any known data input 
technique, such as an icon or keyboard iuput, to indicate the request to the tool 200. Upon 

20 selecting the *TSrew Process" option 3104, the tool 200 may display the exemplary dialog box 
3200 depicted in Fig. 32 to the enterprise affihate. The enterprise affihate may then enter the 
name of a new workflow 3202. After receiving the name for the workflow, the tool 200 creates 
the workflow ia storage (step 2820). 

Figs. 33A-C depict an exemplary workflow definition file 3300 that is produced by the 

25 tool 200 when the workflow 600 depicted in Fig. 6 is created. The name 3302 of the workflow, 
'TLogic Branch Project," is identified in the workflow definition file 3300. Also, as shown in the 
definition file 3300, the workflow 600 does not have a workflow group 3304, The element 3306 
in the workflow definition file 3300 r^resents the "Get Parts" activity 606. Similarly, the 
element 3308 (Fig. 33C) represents the 'TL or Rt Handed?" logic activity 608, the element 3310 

30 represents the *TRight" activity 610, the element 3312 represents the "Lefl" activity 612, the 
element 3314 represents the **Left Special" activity 614, and the element 3316 represents the 
"Complete Assembly" activity 620. The start element 602 is represented by the element 3318, 
and the end element 604 is represented by the element 3320. 
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The next step performed by the tool 200 is to receive an indication of the type of activity 
to be created for the workflow (step 2822 in Fig. 28B). As discussed above, the activity may be 
a standard activity or a logic activity. For example, the workflow 3402 depicted in the user 
interface 3400 of Fig. 34 includes five standard activities 3404, 3406, 3408, 3410, and 3412. 
The workflow 3402 also includes one logic activity 3414! The selection of the type of activity 
may be made by clicking on the icon for a standard activity 3416 or the icon for the logic 
activity 3418. Alternatively, any known data iiQ>ut technique, such as a puU-down menu or 
keyboard input, may be used to select the type of aictivity. 

After receiving an indication of the type of activity, the tool 200 receives the name of the 
activity (step 2824). The names of the activities depicted in the workflow 3402 are included 
with the activity. Thus, the name of activity 3404 is "Assignment," the name of activity 3406 is 
"Analysis,*' etc. 

Returning to the example workflow 600 depicted in Fig, 6, the name of the first activity 
606 is "Get Parts," which is identified by the element 3322 in the workflow definition file 3300 
of Fig. 33. Similarly, the name of the logic activity 608 is '*L or Rt Handed?," which is 
identified by the element 3324. The name of the activity 610 is "Right," as identified by the 
element 3326. The name of thQ activity 612 is **Lefl," as identified by the element 3328. The 
name of the activity 614 is "Left Special," as identified by the element 3330. Finally, the name 
of the activity 620 is "Complete Activity," as identified by the element 3332. 

After receiving a name for the activity, the tool 200 receives an indication of the role 
responsible for the activity (step 2826). As discussed above, the Client Interface (via Resource 
Manager Module 206) allows an enterprise affiliate to identify a role or role profile that may be 
assigned to an activity of the workflow. A role profile includes a Rolename that represents a 
"capability" or "skill set," which is needed to perform a task of a plan created firom the 
workflow, where the task corresponds to the activity of the workflow. For example. Fig. 35 
depicts a user interface 3500 displayed by the Client Interface to receive a role profile. In the 
implementation shown in Fig. 35, the Client Interface receives a Rolename 3502 (e.g., 'Troject 
Manager") for the role profile via the enterprise affiliate clicking on an "Add" button 3504 and 
ttien entering Rolename 3502 in a dialog box 3506 that is displayed by the Client Interface. In 
another implementation, the CUent Interface may also receive as additional entries (not shown) 
to dialog box 3506 a skill and an associated skill level for Rolename 3502 as part of this role 
profile. For Example, the enterprise affiliate may indicate to the Chent Interface via the 
additional entries to dialog box 3506 that the Rolename 3502 of 'Troject Manager" be 
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associated with a skill entitled "Object-Oriented software programming" and with a skill strength 
of "7" on a scale of 10. Assuming an enterprise aflSliate is developing a workflow for producing 
a software development tool, the enterprise affiliate may assign to activities in the workflow the 
'Troject Manager*' role profile with this skill and skill level. Thus, when a plan is created &om 
5 this workflow, a resource having the appropriate skill and skill level will automatically be 
assigned by the Client Interface to tasks corresponding to the activities with the 'Troject 
Manager" role assignment. 

The tool 200 stores the role profiles in association with the selected workflow activity on 
WebDAV Storage 142. The tool 200 saves significant costs in developing multiple workflows 

10 by allowing the enterprise affiliate to store the role profiles in association with the selected 
workflow, activity on WebDAV Storage 142 so that the role profiles niay be available for the 
enterprise afiShate to assign to an activity of another workflow that is also related to the selected 
workflow activity. In one implementation, the Client Interface stores the role profiles in a single 
role definition file (not shown) on WebDAV Storage 142. In another implementation, the Client 

15 Interface stores the role profiles in separate files (not shown) on WebDAV Storage 142. Each 
separate file has a name that is the same as the received Rolename 3502. In this implementation, 
using known WebDAV protocol, the Ghent Interface defines an associated WebDAV property 
having a common name, such as "role profile," so that the CUent Interface may later retrieve the 
role profiles stored on WebDAV storage. 

20 The role profiles may also be stored with the workflow definition file. As shown in the 

workflow definition file 3300 depicted in Fig. 33, the role profile 3334 for the "Get Parts" 
activity 606 indicates that the role responsible for the activity is "Assembled' 3336. Similarly, 
the role profile 3338 for the 'Z. or Rt Handed?" activity 608 indicates that the role responsible 
for the activity is "Assembler" 3340, The role profile 3342 for the *Tlight" activity 610 indicates 

25 that the role responsible for the activity is "Assembler" 3344. The role profile 3346 for the 
*Xefl" activity 612 indicates that the role responsible for the activity is "Assembler** 3348. The 
role profile 3350 for the 'T^eft Special" activity 614 indicates that the role responsible for the 
activity is "Assembler*' 3352. Finally, the role profile 3354 for the "Complete Assembly" 
activity 620 indicates that the role responsible for the activity is "Assembler" 3356. 

30 The next step performed by the tool 200 is to determine whether the activity has any 

predecessor activities (step 2828). If the activity does have a predecessor activity, the tool 200 
receives an indication of the predecessor activities from the workflow definition file (step 2830). 
After checking for any predecessor activities and/or receiving the predecessor activities, the tool 
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200 detennines whether the activity has' any successor activities (step 2832).' If the activity has a 
successor activity, the tool 200 receives an indication of the successor activities j&om the 
workflow definition file (step 2834). In the user interface 3400 of Fig. 34, the 'Tath" icon 3420 
is used to connect the predecessor activity to the successor activity. For example, in the 
5 workflow 3402, a path 3422 was drawn jfrom the "Assignment" activity 3404 to the "Analysis" 
activity 3406. Thus, the "Assignment" activity 3404 is the predecessor activity to the 
"Analysis" activity 3406, and the "Analysis" activity 3406 is the successor activity to the 
"Assignment" activity 3404. Alternatively, a '^Vertical Fork/Join" icon 3424 or a *'Horizontal 
Fork/Join" activity may be used to connect more than one predecessor activities to a successor 

10 activity, or to connect a predecessor activity to more than one successor activities. 

Li the workflow 600 depicted in Fig. 6, the activity ID 3358 of the "Get Parts" activity 
606 is "10." The predecessor 3360 to the "Get Parts" activity 606 has an ID of "11" 3362, 
. which corresponds to the start element 602. The successor 3364 to the "Get Parts" activity 606 
has an ID of "1522" 3366, which corresponds to the or Rt Handed?" logic activity 608. The 

15 predecessor 3368 to the "L or Rt Handed?" logic activity 608 has an ID of "10" 3358, which 
corresponds to the "Get Parts" activity 606. Because the 'X or Rt Handed?" activity 608 is a 
logic activity, it has both a default successor and a non-default successor. Thus, the workflow 
definition file 3300 identifies two paths out of the "L or Rt Handed?" logic activity 608, one 
path 3370 has an ID of "1525" 3372, which corresponds to the 'TRighf ' activity 610, and ttie 

20 other path 3374 has an ID of "1523" 3376, which corresponds to the *T^ft" activity 612. The 
element representing the "L or Rt Handed? logic activity 608 also identifies that the default path 
3378 has an ID of "1525" 3372, which coiresponds to the *'Right" activity 610. The predecessor 
3380 to the '*Right" activity 610 and the predecessor 3382 to the "Left" activity 612 have an ID 
of "1522" 3366, which corresponds to the "L or Rt Handed?" logic activity 608. The remaining 

25 predecessor and successors follow this convention. 

After checking for any successor activities and/or receiving the successor activities, the 
tool 200 determines whether the activity has any on-entry scripts (step 2836). An on-entry script 
is a step to be performed by the tool 200 upon entry into the activity. For example, the on-entry 
script may send an email notifying an interested user about the activity being started. The on- 

30 entry script may also send a dialog box to an enterprise affiliate to obtain data in real-time, or 
send a request to a separate device to gather input, e.g., by sending a message to a computer to 
receive data files. Other examples of on-entry scripts include checking stock levels and issuing 
reorder commands, if necessary, or paging the user assigned to perform the activity. If the 
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activity has an on-entry script, the tool" 200 receives an indication of the dn-entry scripts (step 
2838). After checking for any on-entry scripts and/or receiving the on-entry scripts, the tool 200 
determines whether the activity has any on-exit scripts (step 2840 in Fig. 28C). An on-exit 
script is a step to be performed by the tool 200 upon exiting the activity. For example, the on- 
5 exit script may send an email notifying an interested user about the end of an activity. Other 
examples of on-exit scripts include sending a message to another device to have the other device 
perform enterprise application integration, notifying a downstream consumer about the activity 
so that the consimier knows what is coming, and placing an activity on a user's personal 
calendar. If the activity has an on-exit script, the tool 200 receives an indication of the on-exit 
10 scripts (step 2842). For example, the. "Complete Assembly*' activity 620 depicted in Fig. 6 
includes both an on-entry script 3384 as well as an on-exit script 3386. Upon entering the task 
created from the "Complete Assembly" activity, the tool 200 sends an email to the owner 
indicating that the 'TDebugging period started" 3388, Prior to exiting the task created from the 
"Complete Assembly" activity, the tool 200 sends an email to the owner indicating that the 
1 5 ^TDebugging finished" 3390. 

After checking for any on-exit scripts and/or receiving the on-exit scripts, the tool 200 
determines whether the activity has any input (i.e., begin or starting) conditions (step 2844). If 
the activity has an input condition, the tool 200 receives an indication of the input conditions 
(step 2846). Example input conditions are to expect an artifact required for the task to have a 
20 specific status. After checking for any input conditions and/or receiving the input conditions, 
the tool 200 detfemiines whether the activity has any output (i.e., exit or ending) conditions (step 
2848). An example exit condition could be to automatically check the quality of an artifact 
generated by the task. If the artifact meets quality standards, the task completion occxirs; 
otherwise, the task completion is rejected and the "user is informed that more quality is reqiiired. 
25 If the activity has an output condition, the tool 200 receives an indication of the output 
conditions (step 2850). The output condition 3391 for the "Get Parts" activity 606 has an ID of 
"1527" 3392 (Fig. 33B), and is a document-type condition, as indicated by the "linkablel" 
identity 3393 in the element 3394 representing the condition 3391. In general, based on the 
condition 3391, the tool 200 (in particidar, the Workflow Engine 222) monitors the state of an 
30 artifact for an activated "Get Parts" task created from the "Get Parts" activity 606 until the state 
of the artifact is the "INITIAL" state 3395 before the tool 200 continues with the next task in the 
plan. .Similarly, the output condition 3396 for the "Right" activity 610 has an ID of "1533" 
3397. The output condition 3 3 96 for the '*Right" activity 610 is also a document-type condition, 

-29- 



wo 02/19224 PCT/USOl/27177 
as indicated by the "linkablel" identity 3398. This condition 3396 signals the tool 200 to 
monitor the state of an artifact iintil it is in the 'BRIGHT" state 3399. 

Fig. 36 depicts an exemplary user interface 3600 displayed by the Client Interface 134 to 
include either a document-oriented 3602 or a script (or logic)-oriented 3604 condition. As 
shown in Fig. 36, the Ghent Interface 134 may receive the request to add a condition to the 
activity via a pull-dowu menu selection 3606. The enterprise afiShate may, however, use any 
known data iaput technique to request that a condition be added to an activity, such as an icon or 
keyboard input, to indicate the request to the Ghent Interface 134. If the enterprise affiUate 
selects a document-oriented condition, the enterprise afiShate may be presented with the user 
interface 3700 depicted in Fig. 37 to identify the properties of the condition to the Ghent 
Interface 134. The condition properties 3702 mclude condition-name property 3704 for the 
document-type condition model. In the example shown in Fig. 37, the Client Interface 134 
receives the condition-name property 3704 via a keyboard input by the enterprise affihate. The 
Ghent Interface 134 uses the condition-name property 3704 to distinguish the condition model to 
be created from other condition models stored on WebDAV Storage 142. The Ghent Interface 
134 may store the document-type condition model file on WebDAV Storage 142 havmg fihe 
same name as the condition-name property 3704. In anotiier implementation, the Ghent 
Interface 134 may store the condition-name property 3704 as a WebDAV property stored in 
association with the document-type condition model file on WebDAV Storage 142. 

The Ghent Interface 134 also receives a link-parameter property 3706 as one of 
Condition properties 3702 for the document-type condition model to be created by the Ghent 
Interface. As shown in Fig. 37, the enterprise affihate may identify Imk-parameter property 
3706 to the Ghent Interface via keyboard mput. Link-parameter property 3706 may be used by 
an enterprise affihate m an activity-related script tiiat is identified to the Client Interface during 
file creation of a workflow as described below. Thus, when executmg the activity-related script 
in a task of a plan created from the workflow, the Workflow Engine 222 in Fig. 2 is able to 
locate the correspondmg document condition so that the corresponding input or output condition 
may be evaluated by the Workflow Engine 222. 

The Ghent Interface 134 may also receive a description property 3708 as one of 
Condition properties 3702 for the document-type condition model to be created by the Ghent 
Interface, When creating a workflow as described below, the Ghent Interface may display 
description property 3708 in association with condition-name property 3704 to allow an 
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enterprise affiliate to effectively choose whether the docximent-type condition" model should be 
assigned to an activity of the woricflow. 

The Client Interface may also receive one or more triggering-event properties 3710 for 
the document-type condition model. In the example shown in Fig. 37, the Client Interface may 
5 receive the triggering-event properties as one of the condition properties 3702 for the document- 
type condition model to be created by the Client Interface. Triggering-event properties 3710 
indicate to the Workflow Engine 222 when to check the state property of a document condition 
as an entry or exit condition of an activated task. Triggering-event properties 3710 may include 
a "Write into document" event 3712, a "Change property of document" event 3714, a 'Tut 

10 docxraient into repository" event 3716, a "copy or move into document" event 3718, and a 
"delete docxmienf ' event 3720, 

Next, the Client Interface 134 receives document state properties 3722 as one of the 
Condition properties 3702 for the document-type condition model to be created by the CUent 
Interface. Document state properties 3722 identify possible values for a state property of a 

15 document condition that is created using the docxmient-type condition model. As further 
explained herein, an enterprise affiliate who has been identified as the responsible owner of an 
activated task may change the state property of a document condition (e.g., from *T)RAFT" to 
"APPROVED") using the Client Interface, which sends a request to WebDAV Server 140 in 
Fig. 2 to set the state property of the document condition as indicated by the enterprise affiliate. 

20 Workflow Engine 222 in Fig. 2 may then check the state property of the document condition on 
WebDAV Storage 1 42 when triggering-events 3710 occur. 

The CUent Interface also receives a location property 3724 as one of Condition 
properties 3702 identified by the enterprise affiliate for the document-type condition model. 
Location property 3724 is a unique identifier or URL for a document template that the CUent 

25 Interface uses to create the document condition that is then stored by the CUent Interface on 
WebDAV Storage 142. Location property 3724 may be a location on secondary storage device 
116 of computer 102a or a location on WebDAV Storage 142. As described in greater detail 
below, the document condition is created by the Client Interface 134 when a plan is instantiated 
or created from a workflow having an activity with an entry or exit condition created using the 

30 docviment-type condition model. Finally, the CUent Interface receives appUcation property 3726 
as one of Condition properties 3702 identified by the enterprise affiUate for the document-type 
condition model. AppUcation property 3726 is a imique identifier or URL for an appUcation, 
such as Microsoft Word, that the CUent Interface may run to create an instant of the document 
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template that may be found at the lociation specified by location property 3724. The Client 
Interface uses the instant of the document template to create and store the document condition 
on WebDAV Storage 142. 

Fig. 38 depicts an exemplary user interface 3800 displayed by the Client Interface 134 to 
receive the condition properties 3802 for a logic-type condition model that is to be created by the 
Client Interface 134. The condition properties 3802 include a condition-name property 3804 for 
the document-type condition model, hi the example shown in Fig. 38, the Client Interface 134 
receives tie condition-name property 3804 via a keyboard input by the enterprise affihate. The 
Client Interface 134 uses the condition-name prop^ty 3804 to distinguish the logic-type 
condition model to be created jfrom oflier condition models stored on WebDAV Storage 142. As 
desCTibed below, the Client Literface 134 stores a logic-type condition model file on WebDAV 
Storage 142 fliat has the same name as condition-name property 3804. In another 
implemoitation, the Client Maface 134 may also store condition-name property 3804 as a 
WebDAV property stored in association with the logic-type condition model file on WebDAV 
Storage 142. 

hi the example shown in Fig. 38, the CUmt Interface 134 may receive a description 
property 3806 as one of the Condition properties 3802 for the logic-type condition model to be 
created by the Client Interface 134. When creatmg a workflow as described below, the Ghent 
Interface 134 may display the description property 3806 in association with the condition-name 
property 3804 to allow an enterprise aftiUate to effectively choose whether the logic-type 
condition model should be assigned to an activity of the workflow. 

ITie Client Interface 134 may also receive one or more triggering-event properties 3808 
for the logic-type condition model as one of the condition properties 3802 for tiie logic-type 
condition model to be created by the Chent Interface 134. Triggering-event properties 3808 
indicate to the Workflow Engine 222 when to check an entry or exit condition of an activated 
task. Triggering-evrait properties 3808 include: an "Absolute time" event 3810, a 'Teriod" 
event 3812, a "URL change" event 3814, a "Task change" event 3816, and "any http request" 
event 3818. "Absolute time" event 3810 identifies a trigger for a specific data and time fi-om the 
start time of tiie activated task. 'Teriod" event 3812 identifies a trigger for a specific unit of 
time, such as once every minute. "URL change" event 3814 identifies a trigger when the 
contents of the directory or folder located at the URL changes. 'Task change" event 3816 
identifies a trigger for any time the activated task definition file or associated property changes. " 
For example, when an enterprise afiBliate that is responsible for the task uses the CUent Interface 

-32- 



wo 02/19224 PCT/USOl/27177 
134 to identify that the task is complete, the Client Interface 134 in response sends a request to 
the WebDAV Server 140 to set the status property of the activated task to 'TTNISHED." As 
part of the processing for managing an activated plan as described below, the Workflow Engine 
222 will receive this request before the WebDAV Server 140 and interpret the request as an 
example of a *Task change'* event 3816. Sinularly, "Any http requesf event 3818 indicates to 
the Woikflow Engine 222 to check the entry or exit condition of the activated task when any 
request is received from the Client Interface 134 that pertains to the activated task. For example, 
the Client Interface 134 may send a request to the WebDAV Server 140 to retrieve the activated 
task file so. that a status of flie activated task can be viewed by an enterprise afShate. Workflow 
Engine 222 will receive this request before the WebDAV Server 140 and interpret the request as 
an example of an "Any http request" event 3818. 

The Client Interface 134 may also receive a script 3820 as one of the condition properties 
3802 for the logic-type condition model to be created by the Client Interface 134. Script 3820 is 
executed by the Workflow Engme 222 when a triggering-event occurs that corresponds to'one of 
the triggering-event properties 3808 selected by the enterprise user using the Client Interface 
134. As shown in Fig. 38, Script 3820 may include a script parameter 3822, a script value 3824 
for script parameter 3822, and script content 3826 that may use the script parameter 3822 
initialized to the script value 3824. The enterprise afSUate may provide the script content 3826 
to the Client Interface 134 via a Script Editor User Interface 3900 in Fig. 39. Script Editor User 
Interface 3900 is displayed by the Client Interface 134 when the enterprise afiaUate actuates 
button 3828 on user interface 3800 shown in Fig. 38. Script content 3820 may contain any 
known application program interface (API) script method that would be recognizable by the 
target processor interpreter on computer 106, such as Java"™ Virtual Machine 150 ia Fig. 1. 

After checking for any output conditions and/or receiviag the ou^ut conditions, the tool 
200 determines whether there are any more activities to' add to the workflow (step 2852). If 
there are more activities, the process contmu&s at step 2822 for the next activity. If there are no 
more activities to add to the workflow, the tool 200 receives an indication of the starting pomt 
for the workflow (step 2854). Next, the tool 200 receives an indication of the ending point for 
the workflow (step 2856) before the process ends. 

Fig. 40 depicts an exemplary user interface 4000 displayed by the Client Interface 134 to 
receive the properties of an activity of a workflow. As depicted, the name 4002 of the activity 
(e.g., "Specs Development"), the duration 4004 of the activity (e.g., 1 unit) and the role 4006 
responsible for the activity may be entered by the enterprise afaUate responsible for creating or 
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modifying the workflow. In addition, the enterprise afiBliate may enter an bn-entry script 4008 
as well as aa on-exit script 4010. If the activity represents an entire other workflow, the 
properties of the activity also include the location* 4012 of the sub-process defining the 
workflow. This allows an enterprise to save significant resources by providing a mechanism for 
5 reusing workflows witbin other workflows. Thus, workflows may be modularly built fi-om 
constituent workflows. For example, the defect tracking workflow depicted in Fig. 34 can be 
used inside many "outer" or *liigher-level" processes for software development. 

Creating A Plan From A Workflow 

Figs. 41A-B depict a flow diagram illustrating the process of creating a plan firom a 

10 workflow, i.e., step 306 in Fig. 3. At this point, the enterprise affiliate has akeady selected the 
workflow that will be used to create the plan. Initially, the tool 200 receives an indication of the 
plan name (step 4102). In selecting the plan name, the Ghent Interface 134 allows the enterprise 
affiliate to store the project plan within an identified project plan group so that any enterprise 
affiliate using the Client Interface 134 is able to easily identify related project plans. A process 

15 plan group is a collection of project plans (e.g., a directory or folder containing the collection of 
project plans) created by the CUent Interface 134 on WebDAV Storage 142. For example, the 
software-related project plans may be stored within the same project plan group so that an 
enterprise affiliate is able to quickly locate a desired project plan in order to create a 
corresponding plan using the Client Interface 134. One skilled in the art will appreciate that 

20 Client Interface 134 may store a project plan on WebDAV Storage 142 without associating the 
project plan with a project plan group. Fig. 42 depicts an exemplary user interface 4200 used to 
receive a project plan group. 

In the implementation shown ia Fig. 42, the Chent Interface 134 receives a dialog box 
4202 to enter the name of a new project plan group 4204 (e.g., "Software Projects") after 

25 clicking on a "Create Group" button 4206. Alternatively, if the enterprise affihate decides to 
select an existing project plan group, the tool 200 provides the enterprise affiliate with a Hst 
4300 of available project groups from which the enterprise afiBliate may choose, as depicted in 
Fig. 43. The tool 200 then provides the enterprise aflSliate with a dialog box 4400 to enter the 
name 4402 of the project, as shown in Fig. 44. 

30 The next step performed by the tool 200 is to receive an indication of the working hours 

(step 4104). Fig. 45 depicts, an exemplary timetable 4500. which the enterprise affiliate may use 
to identify the timetable defining a workday. As shown, the enterprise affiliate may select a 
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timetable template 4502 with predefined working hours. The Standard Timetable 4504 includes 
five Working Days 4506 (Monday through Friday) and Working Hours 4508 fi-om 8 a.m. (4510) 
through 12 p.m. (4512) and firom 1 pjn. (4514) until 5 p.m. (4516). Alternatively, the enterprise 
affiliate may select a 24 Hour Timetable 4518 or an Intensive Timetable 4520, i.e., more than 

5 tiie Standard Timetable 4504, but less than the 24 Hour Timetable 4518. The tool 200 also 
receives an indication of the start date and time for the project plan (step 4106). An exemplary 
dialog box 4600 may be used to select the start date and time 4602 and end date and time 4604. 

The tool 200 then retrieves an activity firom the workflow (step 4108). The tool 200 sets 
the start tune of the task equal to the start date and time of the project plan (step 4110). Next, 

10 the tool 200 sets the end time of the task based on the start time of the task, the duration of the 
activity fipm which the task is based, and on the working hours (step 4112 in Fig. 41B). The 
tool 200 then receives an indication of the resource assigned to the task (step 41 14). 

For example, Fig. .47 depicts "an exemplary workflow definition file 4700 that is 
produced by the tool 200 when the workflow 500 depicted in Fig. 5 is created. Fig, 48 depicts 

15 an exemplary project plan definition file 4800 created firom the workflow definition file 4700. 
The element 4702 in the workflow definition file 4700 represents the "Serial 1" activity 506, As 
shown, the "Serial 1" activity 506 has a duration 4704 of 9 hours. If the working hours are 
determined based on the ^'24 Hoxu: Timetable" 4818 and the start date and time for the project 
plan is 9 a.m. on August 1, 2001, the start time 4804 for the "Serial 1" task 4802 is 9 a.m. on 

20 August 1, 2001. The end time 4806 of the task 4802 occurs 9 hours later, i.e., at 6 p.m. on 
August 1,2001. 

Fig, 49 depicts an exemplary user interface 4900 displayed by the Client Interface 134 to 
assign users or resoiur^es to the project and to assign these users specific roles related to the roles 
required by the project. . The tool 200 displays a list of available-users or resources 4902 (on the 

25 left), a list of the assigned users (central), and a list of the roles 4904 (on the right) in a given 
workflow. In this embodiment, the enterprise affiliate is allowed to selectively add or remove 
available resom*ces. to the project by highlighting the resource and selecting either the "Add" 
button 4906 or the '^Remove" button 4908, respectively. Alternatively, the enterprise affiliate 
may add or remove the resources to the project by selecting the "Add all" button 4910 or the 

30 "Remove all" .4912 button, respectively. For each resource, the user can selectively indicate 
(checkboxes) which roles the user should play. Thus, the enterprise afl&liate may identify to the 
tool 200 resources that are capable of performing the role when assigned to a task in the plan. 
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As discussed below, the tool 200 may automatically assign a resource to a role of a task in the 
plan based on the identified, capable resources for the role. 

The properties of an activity may be modified using the exemplary user interface 5000 
depicted in Fig. 50. The user interface 5000 displays the name 5002 of tihe activity, the duration 
5 5004 assigned to the corresponding activity, tiie start date and time 5006 for the activity, the end 
date and time 5008 for the activity, the responsible role 5010 assigned to the corresponding 
activity, the responsible resource or user 5012 assigned to the task, the ovmers 5014 of the task, 
the priority 5016 of the task, the on-entry script 5018 of the task, and the on-exit script 5020 of 
the task. The responsible resource 5012 of the task is the resource with the authority to notify 

10 the tool 200 when the task is complete. The owner(s) 5014 of the task,* on the other hand, are 
notified when the task is started or completed, but do not have the authority to modify the tool 
200 when the task is complete. 

The next step performed by the tool 200 is to detemiine whether there are any more 
activities in the workflow (step 4116). If there are no more activities, the process ends. If there 

15 are more activities, the tool 200 retrieves the next activity (step 4118). The tool 200 then sets 
the start time of the task equal to the end time of the predecessor task (step 4120). The process 
then continues at step 41 12, 

The next activities that are retrieved by the tool 200 are 'Tarallel 1" 510 and *Tarallel 2" 
512. Element 4706 and element 4708 in the workflow delBnition file 4700 represent these 

20 activities 510 and 512. The durations 4710 and 4712 of both of ttiese activities is 24 hours. The 
■ start time 4812 and 4814 of these tasks 4808 and 4810 is equal to the end time 4806 of the 
predecessor task, i.e., 6 p.m. on August 1, 2001. Because the duration 4710 and 4712 of the 
activities 510 and 512 is 24 hours, the end times 4816 and 4818 of these tasks 4808 and 4810 
occur 24 hours later, i,e., at 6 p.m. on August 2, 2001. The next activity retrieved by the tool 

25 200 is ^'Serial 2" 508. The element 4714 in the workflow definition file 4700 represents this 
activity. The duration 4716 of the "Serial 2" activity 508 is 24 hours. The start time 4822 of the 
task 4820 created from the "Serial 2" activity 508 is the end time 4816 and 4818 of the 
predecessor task, i.e., 6 p,m. on August 2, 2001. Because the duration 4716 of the "Serial 1" 
activity is 24 hours, the end time 4824 of the task 4820 is 6 p.m. on August 3, 2001. The project 

30 plan is displayed in the Gantt chart 5100 depicted in Fig. 51. As shown, the "Serial 1" task 5102 
is scheduled to execute from 9 a.m. 5104* on August 1, 2001 (5106) through 6 p.m. 5108 on the 
same day. The *Tarallel 1" task 5110 and the 'Tarallel 2" task 5112 are scheduled to execute 
from 6 p.m. 5108 on August 1, 2001 (5106) through 6 p.m. 5114 on August 2, 2001 (5116). 
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Finally, the "Serial 1" task 5118 is scheduled to execute from 6 pjn. 5114 on August 2, 2001 
(5116) through 6 p.m. 5120 on August 3, 2001 (5122). Note that an enterprise affiliate using the 
Client Interface 134 on the computer 102a may create a plan from the workflow 600 at the same 
time that a second enterprise affiliate using the Client Interface 134 on computer 102n creates a 
5 second plan from the woricflow 600. 

After the project plan is created from the workflow, the plan may be activated. As 
depicted in Fig. 52, the enterprise affiliate may activate the project by selecting the "Activate 
Project" option 5202 from the pull-down rnemi 5200. The enterprise affiliate may, however, use 
any known data input technique, such as an icon or keyboard input, to indicate the request to 
1 0 Client interface 1 34. 

In one implementation, the Client Interfaice 134 then sends an activate request to the 
WebDAV seiver 140 to change the status of the plan definition file to "Active." M discussed 
. further below, the Workflow Engine 222 may intercept this request and process the request in 
preparation for managing the execution of the activated plan. Once the plan is created and 
1 5 stored on WebDAV storage 142, any enterprise affiliate with appropriate privileges (e.g., project 
manager that "owns" the plan) may activate the plan using the Client Interface 134 from any 
computer 102a and 102n. 

Addine A Resource 

Fig. 53 depicts a flow diagram illustrating an exemplary process performed by the Client 
Interface 134 to add a new resource to the list of available resources. The Client Interface 134 . 
may later assign the resource to a plan in accordance with methods and systems consistent with 
the present invention. Initially, the Client Interface 134 receives a request to add a new resource 
(step 5302). As shown in Fig. 54, the Client Interface 134 may receive the request to add a new 
resource via a pull-down menu selection 5402 and 5404 that is chosen by an enterprise affiliate. 
The' enterprise affiliate may, however, use any known data input technique, such as an icon or 
keyboard input, to indicate the request to the Client Interface 134. 

Next, the Client Interface 134 determines whether the request is to import the resource 
information (step 5304). In the implementation shown in Fig, 54, an enterprise affiliate requests 
that the Client Interface 134 import a resource profile containing the resource information by 
choosing the pull-down menu selection 5404. Alternatively, the enterprise affiliate may request 
that the Client Interface 134 create the resource profile fvom resource information that the 
enterprise affiliate provides to the . Client Interface 134. Thus, if the request is not to import the 
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resource information, the Client Interface 134 receives the resource information from the 
enterprise affiliate (st^ 5306). As shown in Fig. 54, the Client Interface 134 may receive 
resource information 5404 for an enterprise affiliate (e.g., a user or person) that may later be 
assigned to a plan by the Client Interface 134 in accordance with processes described ra greater 
detail below. The Resoiurce Information 5404 may include a login name 5408, a resource name 
5410 that the Client Interface 134 is to use when assigning the resource to a task of a plaa, and 
an e-mail address 5412 that the Client Interface 134 or the Workflow Engine 222 may use to 
notify the resource of an assigimient or another event. 

" The CUent Interface 134 may also receive other resource information (not shown) for 
other types of resources (e.g., equipment, faciUties, computer systems, or other known entities) 
that may be assigned to any task of a plan. The other resource information may include: a 
resource name that the Ghent Interface 134 is to use when assigning the resource to a task of a 
plan; a resource owner name that identifies a manager or other enterprise afBliate who is 
responsible for tiie named resource; and an e-mail address for the named resource owner, which 
the Client Interface 134 or the Workflow Engine 222 may notify when the named resource is 
assigned to a task or for another associated event. 

Resource information 5404 may also include one or more skill identifiers that indicate 
one or more capabilities that a task of a plan may require for the task to be completed. Skill 
identifiers may include any foreseeable skill for the named resource, including a user, 
equipment, facihties, computer systems, or other known entities that may be assigned to any task 
of a plan. For example, when the named resource is an enterprise affiUate, the skill identifiers 
that may be identified for the enterprise affiliate may include: "Java programming," 
"architecture," or "carpentry." When the named resource is equipment, the skill identifiers may 
mclude "punch-press," "printing," or ^Windows NT Operating System." Or, when the resource 
is another system, skills may involve the abihty to execute specific fimctions (much hke 
distributed or web services, "credit card vaUdation," "shop for best air fireight shipper prices"). 
Resource information 5404 may also include a skiU strength (not shown) for each skill identifier. 
The skill strengtti may be used by the tool to differentiate one resource firom another resource 
when matching a resource to a role of a task in a plan. 

Resource information 5404 may also include an availabiUty timetable (not shown) that 
indicates to the Client Interface 134 the calendar days, the hours in a weekday, and the hours in a 
weekend day that the named resomrce is available to work. Resource information 5404 may also 
include an assignment timetable (not shown) that has assigned calendar days. The assigned 
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calendar days indicate to the Client Interface 134 which calendar days the named resource has 
been assigned to one or more tasks. In addition, the assignnaent timetable may include unique 
identifiers or URLs for the one or more tasks to which the named resource has been assigned. 
Thus, the Client Interface 134 or the Workflow Engine 222 may access the one or more tasks 
5. that the named resource has been assigned when performing processing for resource leveling of 
a plan in accordance with methods and systems consistent with the present inventiorL 

If the request is to import the resource information, the CUent Interface* 134 receives 
access information for a *Xightweight Directory Access Protocol (LDAP)" resource directory 
entry (e.g., a resomrce profile) on the network 108 of Fig. 1 (step 5308). Fig. 55 depicts an 

10 exemplary user interface 5500 showing access information 5502 received by the Client Interface 
134. Access information 5502 includes an LDAP Server 5504 (e.g., *Trodo") on the network 
108, an LDAP Port 5506 for the Client Interface 134 to communicate with the LDAP Server 
5504, and a resource distinguished name (DN) 5508 identifying the location on LDAP Server 
5504 where the resource profile may be found. The access information 5502 may be default 

15 access information that the Client Interface 134 retrieves firom a configuration file (not shown) 
on the computer 102a, or it may be access information entered by an enterprise afiBdiate. In the 
implementation illustrated in Fig. 55, the access information 5502 may also include: a security 
distinguished name (DN) 5510, a password 5512, and a login alias 5514. Security DN 5510 
identifies to the CUent Interface 134 where a security profile for the enterprise affiliate is 

20 located. The Client Interface 134 uses the password 5512 and the login aUas 5514 to access the 
resource information on the LDAP Server 5504 in accordance with privileges identified in the 
security profile. 

Having received the access information for the LDAP directory entry on network 108, 
the Client Interface 134 retrieves the resource information using the LDAP access information 
25 (step 5310). The resource information that the Client Interface 134 retrieves includes resoiirce 
profiles for a user, equipment, facihties, computer systems, or other known entities that may be 
assigned to any task of a plan. 

After the resource information is received firom the enterprise affiliate or is retrieved 
usiQg LDAP access information, the CUent Interface 134 stores the resource information in 
30 resource profiles on the WebDAV Storage 142 (step 53 12). 

Fig. 56 depicts an exemplary resource file 5600 that the CHent Interface 134 may use to 
store resource profiles 5602, 5604. 5606, and 5608 on WebDAV Storage 142. As shown in Fig. 
56, the resource profile 5600 includes a unique identifier or URL 5612 where the resource 
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profile 5600 is to be stored on the WebDAV Storage 142, Each resource profile 5602, 5604, 
5606, and 5608 may be stored s^arately by tiie Client Interface 134 on WebDAV Storage 142. 
In the implementation shown in Fig. 56, the resource profile 5602 includes resource information 
5610 that corresponds to an enterprise affiliate that may be assigned to a task of a plan. In 
5 another implementation, the resource information 5610 may be added as properties rather than 
as the content of the resource profile 5602 on WebDAV Storage 142. This implementation may 
be advantageous as the Client Interface 134 or the Workflow Engine 222 may use a known 
WebDAV method to retrieve resource profiles fi-om the WebDAV Storage 142 that have the 
same property. For example, the WebDAV *TropFind" method may be used by the Client 
10 Interface 134 or the Workflow Engine 222 to retrieve the resource profiles having a skill 
identifier of "Java Programming" so that an available resource having this skill can be assigned 
to a task in accordance with processes described below. 

Managing A Plan 

Fig. 57 depicts a flow diagram illustrating an exemplary process performed by the 

15 Workflow Engine 222 to manage the execution of an activated plan. The Workflow Engine 222 
may execute the process in Fig. 57 for each activated plan stored on WebDAV Storage 142. 
Thus, the tool manages the execution of multiple plans simultaneoiisly. 

Initially, the tool 200 waits until the current time and date are later than the start time and 
date (step 5702) of the plan. Alternatively, a plan may not require a start time and date for each 

20 plan. Rather, the start time and date may be incoiporated as an input condition for each task. At 
this point, the tool 200 selects the current next task (or tasks in the' event of parallel tasks) &om 
the activated project plan created firbm a workflow (step 5704). Note that the Workflow Engine . 
222 may retrieve the plan firom WebDAV storage. Next, the tool 200 detemiines whether there 
is an input condition (step 5706). If there is an input condition, the tool 200 waits to see if the 

25 triggering event (described above) is met before it checks to see if the input condition is met 
(step 5708). If the input condition required monitoring of certain items on a periodic basis, the 
Workflow Engine 222 will add this event to its "Event Monitoring" log. After the input 
condition is met or if there is no input condition, the tool 200 stores the actual start time (step 
5710). The next step performed by the tool 200 is to determine whether there is an on-entry 

30 script to execute, such as a message to send to the resource (step 5712 in Fig. 57B). If there is 
an on-entry script, the tool 200 performs the on-entry script (step 5714). After performing the 
on-entry script or if there is no on-entiy script, the tool 200 detemiines whether there is an 
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output condition (stq) 5716). If there is an output condition, the tool 200 waits to see if the 
triggering event (described above) is met before it checks to see if the output condition is met 
(step 5718). After the ou^ut condition is met or if there is no output condition, the tool 200 
determines whether there is an on-exit script (st^ 5720). If there is an on-exit script, the tool 
5 200 performs the on-exit script (step 5722). After performing the on-exit script or if there is no 
on-exit script, the tool 200 stores the actual end time (st^ 5724). Then the tool 200 determines 
whether there are any more tasks in the project plan (step 5726). If there are no more t as k s, the 
process ends. Otherwise, the process returns to step 5704 and selects the next task. 

The plan 5800 created from the workflow 500 depicted in Fig. 5 is shown in Fig. 58. As 

10 shown in Fig. 58, "Serial 1" task 5802 is scheduled to begin at 9 a.m. 5804 on August 1, 2001 
(5806) and end at 6 pjn. 5808 on the same day. The parallel tasks 5,810 and 5812 are scheduled 
to start at the completion of the "Serial 1" task 5808, and are scheduled to end at 6 p.m. 5814 on 
August 2, 2001 (5816). The "Serial 2" task 5818 is scheduled to begin upon completion of the 
parallel tasks 5814 and is scheduled to end at 6 p.m. 5820 on August 3, 2001 (5822). Fig. 59* 

15 depicts an exemplary project plan definition file 5900 corresponding to the plan 5800 of Fig. 58. 

Upon activation, the "Serial 1" task 6002 begins execution, as depicted by the task 6004 
in the Gantt chart 6000 of Fig. 60. Contrary to the plan, however, the "Serial 1" task ends earlier 
than planned. As depicted in Fig. 61, the actual properties 6100 of the "Serial 1" task 6102 
include the actual-start-date 6104 (i.e., year-2001 month-8 day-1 hour-9) and actual-finish-date 

20 6106 (i.e., year-2001 month-8 day-1 hour-14, i.e., 2 p.m.). The actual execution 6204 of the 
"Serial 1" task 6202 is shown in the Gantt chart 6200 of Fig, 62. 

Because the "Serial 1" task 6202 ended earlier than planned, both the *Tarallel 1" task 
6206 and the '^Parallel 2" task 6208 begin execution at 2 p.m. 6210 rather than waiting until their 
scheduled start time of 6 p.m. The earlier execution 6212 and 6214 of these tasks 6206 and 

25 6208 is also depicted in the Gantt chart 6200. As depicted in Fig. 63, the actual properties 6300 
of the 'Tarallel 1" task 6302 and the 'Tarallel 2" task 6304 include the actual-start-date 6306 
(i.e., year-2001 month-8 day-1 hour-14) and actual-finish-date 6308 (i.e., year-2001 month-8 
day-2 hour-O). The actual execution 6406 and 6408 of the 'Tarallel 1" task 6402 and the 
'Tarallel 2" task 6404 is shown in the Gantt chart 6400 of Fig. 64. The Gantt chart 6400 also 

30 visually indicates that the start time 6410 for the tasks 6402 and 6404 was 2 p.m. on August 1, 
2001, while the end time 6412 for the tasks 6402 and 6404 was 12 a.m. on August 2, 2001. 

Finally, the execution of the "Serial 2" task 6414 begins at 12 a.m. on August 2, 2001 
(6412). As depicted in Fig, 65, the actual properties 6500 of the "Serial 2" task 6502 includes 
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the actual-start-date 6504 (i.e.,. year-2001 month-8 day-2 hour-0) and act^ial-finish-date 6506 
(i.e., year-2001 month-8 day-2 hour-12). The actual execution 6604 of the "Serial 1" task 6602, 
the actual execution 6608 of the "Parallel 1" task 6606, the actual execution 6612 of the 
'Tarallel 2" task 6610, and the actual execution 6616 of the "Serial 2" task 6614, are shown in 
tibe Gantt chart 6600 of Fig. 66. 

While various embodiments of the present invention have been described, it will be 
apparent to tiiose of skill in the art that many more embodiments and implementations are 
possible that are within the scope of this invention. Accordingly, the present invention is not to 
be restricted except in light of the attached claims and their equivalents. 
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What is claimed is : 

1. A method in a data processing system having a workflow comprising a plurality 
of activities, wherein each of the activities has a duration, and wherein a predecessor one of the 
pluraUty of activities occurs before a successor one of the plurality of activities, the method 
comprising the steps of: 

creating a plan firom the workflow, wherein the step of creating the plan comprises the 
steps of: 

creating a predecessor task from the predecessor activity, wherein the st^ of 
creating the predecessor task comprises the steps of: 

receiving an indication of a predecessor start time for thte predecessor 
task; 

setttQg a predecessor end time for the predecessor task equal to the 

predecessor duration after the predecessor start time; and 
receiving user input indicating a predecessor resource assigned to the 
predecessor task; and 
creating a successor task from the successor activity, wherein the step of creating 
the successor task comprises the steps of: 
setting a successor start time equal to the predecessor end time; 
setting a successor end time equal to the successor duration after the 

successor start time; and 
receiving user input indicating a successor resource assigned to the 
successor task; 
receiving an indication to activate the plan; 
activating the plan; and 

monitoring the activated plan, wherein the step of monitoring the activated plan 
comprises the steps of: 

notifying the predecessor resource to begin the task at the predecessor start time; 
determining when the predecessor task has completed; and 

when it is determined that the predecessor task has completed, notifying the 
successor resource to begin the successor task. 
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2. A method in a data processing system having a workflow comprising a plurality 
of activities, wherem each of the activities has a duration, and wherein a logic one of the 
plurality of activities has a condition, the mettiod comprising the steps of: 

creating a plan from the workflow, wherein the step of creating the plan comprises the 
steps of: 

creating a logic task from the logic activity, wherein the step of creating the logic 
task comprises the step of receiving an indication of a start time for the 
logic task; and 

creating a default task from a defeult one of the pluraUty of activities, wherein tiie 
step of creating tiie default task comprises the steps of: 
setting a default start time equal to the logic start time; and 
setting a default end time equal to the default duration after the default 
start time; 

receiving an indication to activate the plan; 
activating the plai^ and 

monitoring the activated plan, wherein tiie step of monitoring the activated plan 

comprises the steps of: 

determining whether the condition is met; and 
when it is detenniaed that the condition is met, 

creating a non-default task from a non-default one of the plurahty of 
activities, wherein the step of creating the non-defeult task 
comprises the steps of: 

setting a non-default start time equal to the logic start time; and 
setting a non-default end time equal to the non-default duration 
after the non-default start time; and 
replacing the default task with the non-default task. 

3 . A method in a data processing system, comprising the steps of: 
creating a workflow that models a process; and 

generating a plan from the workflow that represents an instance of the process. 

4. The method of claim 3, further comprising the step of creating a different plan 
from the workflow. 
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5. A method in a data processing system having a workflow that models a process, 
the method comprising the steps of: 

generating a plan &om the workflow that reflects an instance of the process; and 
activating the plan to perform the instance of the process. 



5 6. The method of claim 5, further comprising the steps of: 

creating a different plan from the workflow; and 
activating the different plan. 



7. A method in a data processing system having a virtual file system server 
coimected to a network storage medium, the method comprising the steps of: 

10 using the virtual file system server to retrieve a workflow &om the network storage 

medium; 

creating a plan fix>m the woflcflow; and 

storing the plan on the network storage mediimi. 

8. The method of claitn 7, further comprising the steps of: 
15 creating a different plan from the workflow; and 

storing the different plan on the network storage medium. 

9. A con:5)uter-readable medium containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises a virtual file 
system server connected to a network storage medixmi, the method comprising the steps of: 

20 using the virtual file system server to retrieve an activity having a duration from the 

network storage medium; 
creating a task from the activity, wherein the step of creating the task comprises the steps 
of: 

receiving an indication of a start time for the task; and 
25 setting an end time for the task equal to the duration after the start time; and 

storing the task on the network storage medium. 
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10. The computer-readable medium of claim 9, wherein the method further 
comprises the steps of: 

receiving user input indicating a resource assigned to the task; and 
notifying the resource to begin the task at the start time. 

5 11. The computer-readable medium of claim 10, wherein the me&od further 

comprises the step of receiving an indication that the task has been completed by the resource. 

12. The computer-readable medium of claim 9, wherem the activity further includes 
an input condition, and wherem the method further comprises the steps of: 

receiving user input indicating a resource assigned to the task; 
10 determining whether the input condition is met; and 

when it is detemiined that the input condition is met, notifying the resource to begin the 
task. 

13. The computer-readable medium of claim 12, wherein the mput condition 
comprises a change to a state of an artifact 

15 14. The computer-readable medium of claim 9, wherein the method further 

comprises the step of displaying ttie start time and the end time for the task on a timeline. 

15. The computer-readable medium of claim 14, wherein the timeline comprises a 
Gantt chart, 

16. The computer-readable medium of claim 9, wherein the" method further 
20 comprises the step of displaying a graphical representation of the activity. 

17. The computer-readable medium of claim 16, wherein tiie graphical representation 
comprises a flow diagram. 
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18. A computer-readable medium containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises an activity >vith a 
duration, the method comprising the steps of: 

creating a task from the activity, wherein the step of creating the task comprises the steps 
5 of: 

receiving an indication of a start time for the task; and 
setting an end time for the task equal to the duration after the start time; and 
creating a different task from the activity, wherein the step of creating the different task 
comprises the steps of: 
10 receiving an indication of a different start time for the task; and 

setting an end time for the task equal to the duration after the different start time. 

19. The computer-readable mediirai of claim 18, wherein the method ftirther 
comprises the steps of: 

receiving user input indicating a resource assigned to the task; and 
1 5 notifying the resource to begin the task at the start time. 

20. The computer-readable medium of claim 19, wherein the method ftirther 
comprises the step of receiving an indication that the task has been completed by the resource. 

21. The computer-readable medium of claim 20, wherein the method ftirther 
comprises the steps of: 

20 receiving user input indicatitig a different resource assigned to the different task; and 

notifying the different resource to begin the different task at the different start time. 

22. The computer-readable mediiim of claim 21, wherein the method further 
comprises the step of receiving an indication tiiat the different task has been completed by the 
different resource. 
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23. The computer-readable medium of claim 18, wherein the activity further includes 
an input condition, and wherein the method further comprises the steps of: 

receiving user input indicating a resource assigned to the task; 
deteniiining whether the input condition is met; and 
5 when it is detennined that the input condition is met, notifyiug the resource to begin the 

task. 

24. Tlie computer-readable medium of claim 23, wherein the input condition 
comprises a change to a state of an artifact. 

25. The computer-readable medium of claim 18, wherein the method further 
10 comprises the stq>s of: 

receiving user input indicating a different resource assigned to the different task; 
determimng whether the input condition is met; and 

when it is determined that the input condition is met, notib^dng the different resource to 
begin the different task. 

15 26. The computer-readable medium of claim 18, wherein the method further 

comprises the step of displaying the start time and the end time for the task on a timeline, 

27. The computer-readable medium of claim 26, wherein the method further 
comprises the step of displaying the different start time and the end time for the task on a 
different timeline. 

20 28. The computer-readable medium of claim 27, wherein tiae timeline comprises a 

Gantt chart. 

29. The computer-readable medium of claim 18, wherein the method further 
comprises the step of displaying a graphical representation of the activity, 

30. The computer-readable medium of claim 29, wherein the graphical representation 
25 comprises a flow diagram. 
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31. A computer-readable medium containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises an activity with a 
duration, the method comprising the st^s of: 

creating a task from flie activity, wherein the step of creating the task comprises the steps 
5 of: 

receiving user input indicating a resource assigned to the task; 
receiving an indication of a start time for the task; and 
setting an end time for the task equal to the duration after the start time; and 
creating a different task from the activity, wherein the step of creating the different task 
10 comprises the steps of: 

receiving user input indicating a different resource assigned to the different task; 
receiving an indication of the start time for the task; and 

setting an end time for the different task equal to the duration after the start time. 



32. The computer-readable medium of claim 31, wherein the method further 
15 comprises the step of notifying the resource to begui the task at the start time. 

33. The computer-readable medium of claim 32, wherein the method further 
comprises the step of receiving an indication that the task has been completed by the resource. 

34. The computer-readable medium of claim 33, wherein the method further 
comprises the step of notifying the different resoiirce to begin the different task at the different 

20 start time. 

35. The computer-readable medium of claim 34, wherein the method further 
comprises the step of receiving an indication that the different task has been completed by the 
different resource. 
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36. The computer-readable medium of claim 31, wherein the activity further includes 
an input condition, and whereia the method further comprises the steps of: 

determining whether the input condition is met; and 

when it is determined that the input condition is met, notifying the resource to begm the 
5 task. 

37. The computer-readable mediimi of claim 36, wherein the mput condition 
comprises a change to a state of an artifact. 

38. The computer-readable medium of claim 36, wherein the method further 
comprises the step of, when it is determined that the input condition is met, notifying the 

10 different resource to begin the different task. 

39. The computer-readable medium of claim 31, wherein the method further 
comprises the step of displaying the start time and the end time for the task on a timeline. 

40. The computer-readable medium of claim 39, wherein the method further 
comprises the step of displaying the start time and the end time for the different task on a 

1 5 different timeline. 

41. The computer-readable medium of claim 39, wherein the timeline comprises a 
Gantt chart 

42. The computer-readable medium of claim 31, wherein the method further 
comprises the step of displaying a graphical representation of the activity. 

20 43. The computer-readable medium of claim 42, wherein the graphical representation 

comprises a flow diagram. 
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44. A computer-readable medium containing mstructions for controlling a data 
processing system to perform a method, the data processing system comprises a plurality of 
activities wherein each of the activities has a duration and wherein a predecessor one of the 
plurality of activities occurs before a successor one of the plurality of activities, the method 
cotnprising the steps of: 

creating a predecessor task from the predecessor activity, wherein the step of creatiag the 
predecessor task comprises the steps of: 

receiving an indication of a start time for the predecessor task; and 
setting a predecessor end time for the predecessor task equal to the predecessor 
duration after the start time; and 
creating a successor task from the successor activity, wherein the step of creating the 
successor task comprises the steps of: 

setting a successor start time equal to the predecessor end time; and 
setting a successor end time equal to the successor duration after the successor 
start time. 

45. The computer-readable medium of claim 44, whereiu the step of creating the 
predecessor task furdier comprises the step of receiving user input indicating a predecessor 
resource assigned to the predecessor task, and wherein the method fiirther comprises the step of 
notifying the predecessor resource to begin the predecessor task at the start time. 

46. The computer-readable mediimi of claim 44, wherein the step of creating the 
successor task fiirthier comprises the step of receiviag user input indicating a successor resource 
assigned to the successor task, and wherein the method fiurther comprises the step of notifying 
the successor resource to begin the successor task at the successor start time. 
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47. The coinputer-readable medium of claim 44, wherein a different predecessor one 
of the plurality of activities occurs before the successor activity, and wherem Ihe meHiod further 

comprises the steps of: 

creating a different predecessor task fcom the different predecessor activity, wherein the 
step of creating the different predecessor task comprises the steps of: 
receiving an indication of a different predecessor start time for the different 

predecessor taslq and 
setting a different predecessor end time for the different predecessor task equal to 
the different predecessor duration after the different predecessor start 
time. 

48. The computer-readable medium of claim 44, wherein a different successor one of 
the plurality of activities occurs after the predecessor activity, and wherein the method further 

comprises the steps of: 

creating a different successor task from the different successor activity, wherein the step 
of creating the different successor task comprises the steps of: 
receiving an indication of a different successor start time for the different 
successor task; and 

setting a different successor end time for the different successor task equal to the 
different successor duration after the different successor start time. 

49. The computer-readable medium of claim 44, wherein the predecessor task 
comprises a predecessor input condition, and wherein the method fiirther comprises the steps of: 
receiving user ii^>ut indicating a predecessor resource assigned to the predecessor task; 
determining whe^er the predecessor input condition is met; and 

when it is determined that the predecessor input condition is met, notifying the 
predecessor resource to begin the predecessor task. 
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50. The computer-readable medium of claim 44, wherein the predecessor task fiirther 
comprises a predecessor output condition, and wherein the method further comprises the stq)s 
of: 

receiving user irq^ut indicating a successor resource assigned to the successor task; 
detemiining whether the predecessor output condition is met; and 

when it is determined that the predecessor output condition is met, notifying the 
successor resource to begta the successor task. 

51. The computer-readable medium of claim 44, wherein the successor task 
comprises a successor input condition, and wherein the method further comprises the steps of: 

receiving user input indicating a successor resource assigned to the successor task; 
detenhining whether the successor input condition is met; and 

when it is determined that the successor input condition is met, notifying the successor 
resource to begin the successor task. 

52. A computer-readable mediimi containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises a plurality of 
activities wherein each of the activities has a duration and wherein one of the plurality of 
activities and another of the plurality of activities start and end at a same time, the method 
comprisiug the steps of: 

creating a task from the activity, wherein the step of creating the task comprises the steps 
of: 

receiving an indication of a start time for the task; and 
setting an end time for the task equal to the duration after the start time; and 
creating another task from the other activity, wherein the step of creating the other task 
comprises the steps of: 

setting another start time for the other task equal to the start time for the task; and 
setting another end time equal to the other duration after the start time. 
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53. A computer-readable mediiim containing instructions for controlling a data 
processing system to perform a method, the method comprising the steps of: 
creating a workflow that models a process; and 

generating a plan from the workflow that represents an instance of the process. 

5 54. The computer-readable medium of claim 53, wherein the method fiarther 

comprises the step of generating a different plan from the workflow. 

55. A computer-readable medium containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises a workflow that 
models a process, the method comprising the steps of: 

10 generating a plan from the workflow that reflects an instance of the process; and 

activating the plan to perform the instance of the process. 

56. The computer-readable medium of claim 55, wherein the method forther 
comprises the steps of: 

generating a different plan from the workflow; and 
1 5 activating the different plan. 

57. A computer-readable medium containing instructions for controlling a data 
processing system to perform a method, the data processing system comprises a virtual file 
system server connected to a network storage medium, the method comprising the steps of: 

using the virtual file system server to retrieve a workflow from the network storage 
20 medium; 

generating a plan from the workflow; and 
storing the plan on the network storage medium, 

58. The computer-readable medium of claim 57, wherein the method fiorther 

comprises the steps of: 
25 generating a different plan from the workflow; and 

storing the different plan on the network storage medium. 
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59. A data processing system comprising: 
a network storage medium; 

a memory device fiarther comprising a program that creates a workflow that models a 
process, that generates a plan &om the workflow that represents an instance of 
the process, and that stores the workflow and the plan on the network storage 
medixmi; and 

a processor for running the prograia, 

60. The data processing system of claim 59, wherein the workflow comprises a 
plurality of activities, and wherein when the program generates the plan from the workflow, the 
program creates a plmrality of tasks from the plurality of activities. 

61. The data processing system of claim 60, wherein each activity has a duration, and 
wherein when the program creates the plurality of tasks from the plurality of activities, the 
program receives an indication of a start time for each task and sets an end titne for each task 
equal to the corresponding duration of the activity after the corresponding start time. 

62. The data processing system of claim 61, wherein the program further activates 
the plan, wherein when the program activates the plan, for each task of the plan, the program 
notifies a resource assigned to the task to begin the task. 

63. The data processing system of claim 59, wherein the program further creates a 
different plan from the workflow, and stores the different plan on the network storage medium. 

64. A system comprising: 

means for creating a workflow that models a process; and 

means for generating a plan from the workflow that represents an instance of the process. 
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<?xml verslon:="1^0;^ncoding="UTF-8" ?> 
- <process group=*'*^ame^"Loglc Branch Project"> 

3358 <description /> 3302 

"<rol&-Rame=*'Assembler" /> 

octivity ld=*'10" name=^'Get Parts" responsiblerole 

<description /> ^ 3322 \ 

<defduration unlts=s "units" value="l" /> V ooo>i 

3306 < < predecessors Jd Id^^'llVs 3360 ^^^^ 

^ <successorsJd ld="1522" /> 3364 

<outL_aritfacts id="1527" /> 3391 

</activity> ^,^3376 

octivity id="1523" name^"Left" responsIbIert)Ie="Ass( 
<description /> ^-^328 \ 

<defduration units="units" va!ue="l'' /> V 



="As£ierTi 



3336 



imbler"> 



3348 



mbler"> 



3346 



'3382 



V 



<predecessorsJd Id="1522*' /s 

< successors Jd id="1524" /> 
<out„arItfacts id="1529" /> 3352 

</activity> 

ocbVity id="1524" name="Left Special" responsiblerole-''Assbmbler"> 
<descriptlon /> ^^330 
<defduratIon units="unlts" vaYue="l" /> 

< predecessors Jd ld="1523" /> 

< successors Jd Id ="15 26" /> 3344 
<out_aritfacts ld="1531" /> v3ot*+ 

</activlty>^— 3372 { 
octivity id^"1525" name=?"Right" responsiblerole="Assfembier"> 

<description /> — 3326 

<defduration units="units" value= " 



3350 



26 ( 

3="1" /> V 



3380 



3342 



3356 



3354 



3316 



3384- 



3386- 



< predecessors Jd id="1522" /s 
<successorsJd ld="1526" /> 
<out„aritfacts id="1533" /sv qqqr 

</activity> 339b 

<activity id="1526" name:="Complete Assembly" responslbIerole="Ass^mbler"> 
< description /> 3332 \ 

<defduration units="units" value=="l" /> V. 
<onEntry> oooo 
- <![CDATA[ 

send Mail (getOwnerEmailO, "Detfugging period started", 
"All the SCR flies should be placed into the '%SCR_FOLDER%' folded); 

]]> 
</on Entry > 

/ - <I[CDATA[ ^5^yU 

sendMaiI(getOwnerEmaiiO, "Debugging finished. No more SCRs found", ""); 

^ </onExit> 

<predecessorsJd id="1524" /> 

< predecessors Jd id="1525" /> 

< successors Jd id="12" /> 
<out;_aritfacts id="1535" /> 

</activity> 
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^^^3392 ^ 3393 

- ortlfact ld«"1527" tdenttty-^iinkablel** name=" Document is INITIAL"> 
<desaiption>The condition becomes true when the Document^Vo artifact gets the 

INXTZAL state. To make this condition valid you should define the (VbDocumentVo 
parameter and optionally define the document template and the application to 
open the document. </descriptlon> 
3394 \ <type>nnkable</Cype> 

<Hnk Hnk="%Document«Vb" /> 
<state>INITIAL</gate>_ 
. <event ^="1528" /> 3395 
\ </artlfact> 

- <artifact id="l529'' identity="linkablel*' name=" Document Is LEFT"> 
<description>The condition becomes true when the % Documents artifact gets the 

LEin' state. To make this condition valid you should define the <Vb Documents^ 
parameter and optionally define the document template and the application to 
open the document. </description> 
<type> Iinkable</type> 
<nnk link="yoDocumento/o'' /> 
<state> LEFT</state> 
<event ld="1530"/> 
</artifact> 

_ ortifact id="153l" identity ^'iinkablel" name='* Document is LEFT SPECrAL"> 

<descrlptlon>The condition becomes true when the «Vb Document<Vb artifact gets the 
LEi=T SPECIAL State. To make this condition valid you should define the 
<Vb Documento/o parameter and optionally define the document template and the 
application to open the document. </descript{on> 
<type> linkable </type> 
<link link^^VoDocumentVo" /> 
<state>LEFT SPECIAL </state> 
<event id="1532" /> 
</artifact> 3397 — ^ 

- ortlfact id=i^533" identrty=i"linkablel" name=*'Document is RXGHT"> 
<descriptlon>The condition becomes true when the % Documents artifact gets the 

RIGHT state. To make this condition valid you should define the c^Document<Vb 
parameter and optionally define the document template and the application to 
open the document.</de5cription> 
<type>linkable</type> 
<Unk nnk5="«»/oDocumento/o" /> 

<state>RIGHT<i^tete> o-aoQ 

<event ld=:"1534- /> o^^i* 
</artifact> 

- ortifact ids^lSSS" identity="linkablel" name=" Document is APPROVED"> 
< description > The condition becomes true when the Documents artifact gets the 

APPROVED state. To make this condition valid you should deHne the 
^J6 Documents parameter and optionally define the document template and the 
application to open the document. </descrlpUon> 
<type> linkable</type> 
<Unk Iink="%Documento/o" /> 
<state> APPROVED </state> 
<event id="1536" /> 
</artifact> 
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FIG. 33C 

^3366 ^3340 

<logic id=s'^522" name^p^L or Rt Handed?" responsibleroie="Assembler"> 
<description /> ^—3324 \ 

- <script> V. 3338 

- <1CCDATAC 
approvedO 

]]> 
</script> 

< predecessors Jd id="10'' /> 3368 

<other_pathJd id="1525" /> Z^^ZO 

<other_path_id id="1523" /> 3374 

<defpathjd Id^"1525"/> 3378 

<syncbar id="ll"> 3362 

< description /> 

<startBar>T</startBar> 

<successors_id id="lO'' /> 
</syncbar> 
<syncbar id="12"> 

< description /> 

<endBar>T</endBar> 

<predecessors_id id="1526" /> 
</syncbar> 

<event id="X528" name=*'??Event_name''> 

< description > ??Event_desc</descnption > 

< type > REQU EST-G U ARD </ty pe > 
<request>PROPPATCH</request> 

</event> 

<event id="1530" name=*'??EventL_name*'> 
<description>??Event„desc</description> 

< type > REQ U EST-G U ARD </ty pe > 
<request>PROPPATCH</request> 

</event> 

<event id=*'1532" name="??EvenlL_name"> 

<description>??Event„desc</description> 

<type>REQUEST-GUARD</type> 

<request>PROPPATCH</request> 
</event> 

. <event id="1534" name=*'??Event_name"> 
<descripb*on>??Event_desc</description> 
<type>REQUEST-GUARD</type> 
<request>PROPPATCH</reque5t> 
</event> 

. <event id="1536'' name="??Event_name"> 

< descri ption > ?? Event_desc</description > 
<type>REQUEST-GUARD</type> 
<request> PROPPATCH</request> 

</event:> 
/process> 
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function chedongQ 
[ 

var msg = 

. var SCRFdcter = new UFa4:'%SCR_FOLDB^%"); 

H (!SCRFolder.e)dslsO II ISCRFolder jsFoWerO) return false; 

var cHrectoryList *= SCFtFolder.getChildrenO; 

for ( I -0 ; i < directoryUst Jenglh ; 
- { 

var nextnie = directoryLtetli]; 

if C nextTile.ciieci^PropertyC'vvoricflow", "status", ) 

{ 

nextfTIe,setPropertyC workflow", "status", "inwortc"); 

var processReference - getURLO.getProperlyCPROPffeTlES". ''ProcessReference"); 
generateNewRequestC'open", processReference, "SCR", nextne.patli); 
sendMailCgetOwnerEmailQ, "New SCR generated: " + nextRIe.url. ""); 
> y/ENDlF 
> y/BMDFOR 

return getPercentQ == 1 00; 

} 

Dhec^dngC); 





4012 



4004 



-4006 
-4008 
4010 



4002 



wo 02/19224 



PCT/USOl/27177 



25/42 



FIG. 41A 



Begin J) 



Receive Indication 
of Plan Name 



Receive Indication 
of Working Hours 



4102 



4104 



.4106 



Receive Indication of 
Start Date and Time 



Retrieve 
Activity 



,4108 



Start Time of Task = 
Start Date and Time 



,4110 



26/42 



PCT/USOl/27177 



FIG. 41 B 




Set End Time of Task Based on Start 
Time. Duration, and Working Hours 



4112 



Receive Indication of 
Resource Assigned to Task 



,4116 

'Any More^X ^ N 
Activities?^ 



4118 




Retrieve 
Activity 



c 



End 



Start Time of Task = End 
Time of Predecessor Task 



.4120 



wo 02/19224 



PCT/USOl/27177 



27/42 • 



FIG. 42 



4200 



;-42t)6 



Pt0ject 
Expert 

if E 



Pro^ectGroupi 
■%i.Pro}ectGroup2 ^2Q2 



Type name for prgjecf group 



[ Software Prgjects 



-4204 



QK 



.Cancei 



<Pfevtous 



FIG. 43 ^4300 

✓ 3p6dfyej5rc^ed group tor -anew prpiect 



' http:Moccdhost808QA¥ebdav 
ProjectGroupl 
*^ Pro5erfGroup2 
Software Projecte\ 



FIG. 44 

. ^eclfyifi? iji^fe of the" new project Joe tf"*© groyp* ^fRvare'Pro]Ec|^r 



PrE^Ttame::-' : Hetto Wcwld App ,J 



'4402 



wo 02/19224 



28/42 



PCTAJSOl/27177 



FIG. 45 



-4500 



Spec^ timetable '=ftx project 



4502 



4506 




•• "'^ ' ■■ '■ -'.v^r ^52cf :::-.v ■■' 

O Intensive Tlmelabif - - ■ ' .* " • ' -"^ 



FIG. 46 ^4600 

FIrtsh date (mmtftiVY): 



-4602 



SnOCOOl 5PM 



-*604 



PCT/USO 1/27177 



29/42 



FIG. 47 

4700 




<?xml version="1.0*' encodmg="UTF-8'' ?> 
<process groupss"" name="Serial El Para!lel"> 

<description /> 

<role name="Worker" /> 
- - <ac±ivity id="10'' name="Serial 1" responsiblerole="Worker"> 
<description /> 

<defduratlon units="hours" value="9'' /> 4704 

< predecessors Jd id="ll" /> 
<successorsJd id="1522" /> 
</activity> 

^- ocUvity id="1523" name="Paranel 1" responsiblerole= "Worker" > 
< description /> 

<defduration units="hours" value="24" 4710 

< predecessors Jd id="1522" /> 
<successorsJd id="1525*' /> 

^ </actlvity> 

" - octivity id=''1524" name="ParalIel 2" responsib!erole= "Worker" > 
< description /> 

<defduration units="hours" value="24" /> 4712 

< predecessors Jd id="1522" /> 
<successorsJd id="1525" /> 

^ </activity> 

^ - <activity id="1526" name="Serial 2" responslbIero)e= 'Worker" > 
<description /> a-tac^ 
<defduration unIts="hours" value="24" /> 4716 

< predecessors Jd ids="1525"/> 
<successorsJd id="12'' /> 

</activity> 

- <syncbar id=*'ll"> 

<description /> 
<startBa r> T</sta rtBar> 
<successorsJd ld="10" /> 
</syncbar> 

- <syncbar Id="l2"> 

< description /> 
<endBar>T</endBar> 
<predecessorsJd id-"1526"/> 

</syncbar> 

- <syncbar id=''1522" nanne="SyncBarHl"> 

<description /> 
<predece5SorsJd id="10" /> 
<successorsJd id="1523" /> 
<successorsJd id="1524" /> 
</syncbar> 

- <5yncbar ld="1525" name="SyncBarH2''> 

<description /> 

<predecessorsJd id="l523" /> 
<predecessorsJd id=*'1524" /> 
<successorsJd id=«1526" /> 
</syncbar> 
</process> 
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FIG. 48 4800 

<?xml verslon^^l.O" encoding="UTF-8" ?> 

<A:plan name="Serial_And_ParaIlel" userid=*'JK" xmlns:A= "workflow" > 
^ <A:description> 
- <![CDATA[ 
No Description 
]]> 

</A: description > 
^ <A:task activltyID="10" caption= "Serial 1" 

link="Sample_Project„Plans/Serlal_And_Parallel/Task_2.xmr name=**Task_2" 
o wner= "Worker" 

processURL="http://locaIhost::8080/webdav/ProcessGroup2/Processl.xmr 
type="generar userid=*'JK"> 

>ior.o/ <A:stBrt>2001 8 1 9<:/A:start> 4804 

4802 <^ <A:finish>2001 8 1 18</A:nnlsh> 4806 

<A:supertasic namess"TasK_l" /> 
<A:user>JK</A:user> 
<A: successor name='TasK_3*' /> 
<A: successor name="Task_4'' /> 
</A:task.> 

- <A:task activityID="1523'' caption="Parallel 1" 
link="Sample_Project_Plans/Serial_And„Parallel/Task^3.xml- name="Task_3" 
owner= "Worker" 

processURL="http://localhost:8080/webdav/ProcessGroup2/Processl.xmr 
type=="general" userid="JK"> 

<A:start>2001 8 1 18</A:start> 481 2 

4808 \ <A:finish>2001 8 2 18</A:finish> 481 6 

<A:supertask n3me="TasK-l" /> 
<A: user>JK</A:user> 
< A: predecessor name="TasK_2" /> 
<A:successor name-*TasK_5'' /> 
</A:task> 

- <A:task actlvityID="1524" caption = "Parallel 2" 
link="Sample_Project_Plans/Serjal_^nd_Parallel/Task_4.xnrir name="Task_4" 
owner="Worker" 

processURL="http://locaIhost:8080/webdav/ProcessGroup2/Processl,xmr 
type="generar userfd="JIC> 

yicnn/ <A:start>2001 8 1 18</A:start> 4814 

401U^ <A:finish>2001 8 2 18</A:finis!i> 4818 

<A:supertask name="TasK-l" /> 
<A:user>JK</A:user> 
< A: predecessor name="Task_2" /> 
<A:successor name=*Task_5" /> 
</A:task> 

<A:task activityID="1526" caption="Serial 2" 

link="Sample_Project;_Plans/Serial_And_ParaMel/Task_5.xmI" nanne="TasK_-5" 
owner= "Worker" 

processURL="ht±p://localhost:8080/webdav/ProcessGroup2/Processl.xmr 
type="generar userid=*'JK"> >iooo 

/I Qon / <A:start>2001 8 2 18</A:start> TX^^ 

^X!>Z\J<^ <A:finisii>2001 8 3 18</A:nnish> 4824 

<A:supertask name="Task__l" /> 
<A:user>JK</A:user> 
<A:predecessor name="Task_3" /> 
<A: predecessor name="Task^4" /> 
</A:task> 

j:. <A:task activityID="NONE" caption="Ser!al And Parallel" 

Iink="Sample_Project_Plans/Serlal„And_Parallel/Task_l.xmr name="Task_l" 
processURL="http://locaihost:8080/webdav/ProcessGroup2/Processl.xmr' 
type="general" userid="JK"> 
<A:start>2001 8 1 8</A:start> 
<A:finlsfi>2001 8 3 18</A:fin!sh> 
<A:user>JK</A:user> 
<A:subtask name="Task_2" /> 
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<?xml version="1.0" encodIng-"UTF-S" ?> 
- <users> 

<user> 5610 
<id>PH</id> 

J <name> Pointy Hair </nanne> — h o 

5602 \ <email>ph@company.com</email> . 561 2 

<password>ZGV364==</password> J 
uri= **Software„Projects/Hel!o-Worlcl_App/Users_l.xmt=^ 
</user> 
<user> 

<id>MQ</id> 

<name>Mistcr Quality</name> 
5604 s <email>mq@company.cam</email> 
< password > ZG V636 = = </password > 

uri= '*Software_Projects/Hello-World_App/Users_l,xnnr 
</user> 

- <user> 
<ld>MB</id> 

<name>Mlster Build</name> 
5606 <f <eman>mb@company,com</email> 
<password>ZGVS35= = </password> 

url= *'Software„Prpjects/Heilo-World_App/Users_i .xml" 
</user> 

- <user> 
<id>MT</id> 

<name> Mister Tee</name> 
5608 *\ <ennail>mt@company.com</ema!l> 
<password>ZGV470==:</password> 

url= "Software_Projects/Hello-World_App/Users_l.xmr 
</user> 
</users> 
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<?xml version="1.0" encc>dlng="UTF-8" ?> 

<A:plan name=*'Serial_And_Paraller userid="JK" xmlnsiA^" workflow" > 

- <A:description> 

- <![CDATA[ 
No Description 
]]> 

</A:description> 

- <A:task ac±ivityID="10" caption=*'Seria( 1" 

nnk=*'SampIe_Project_Plans/Serial_And_Parallel/Task„2.xmr name="TasK_2" 
owner= "Worker" 

proce5sURL="http://loca!host:8080/webdav/ProcessGroup2/Processl.xmI*' 

type="generar userld="JlC> 
<A:start>2001.8 1 8</A:start> 
<A:nnish>2001 8 1 18</A:finlsh> 
<A:supertask name=:"TasK„l" /> 
<A:user>3K</A:user> 

< A: successor name=''Task_3" /> 
< A; successor name=''Task_.4" /> 

</A:ta5k> 

- <A:task activltyID--1523" caption= "Parallel 1" 

iink="Sample„Project_P!ans/Serial_And„Parallel/Task_3,xml" name=*Task_3" 
owner= "Worker" 

processURL="http://localhost:80SO/webdav/ProcessGroup2/Processl.xml" 

type="generar user1d="3IC> 
<A:start>2001 8 1 18</A:stBrt> 
<A:finish>2001 8 2 18</A:flnish> 
<A:supertask name^^Task,.!" /> 
<A: user>3K</A: user> 
< A: predecessor name="Task_2" /> 
< A: successor name^^Task^S" /> 
</A:task> 

- <A:task acOvityID="1524" captlon= "Parallel 2" 

li'nk="5ample_Project_Plans/S€rial_And_ParaJlel/Tasl^4.xml" name="Task_4" 
owners "Worker" 

processURL="http://localhost:S080/webdav/ProcessGroup2/Processl,xmr' 
type=s"generar userid="JK"> 
<A:start>2001 8 1 18</A:start> 
<A:finish>2001 8 2 lS</A:finish> 
<A:supertask name-"Task_l'' /> 
<A:user>JK</A:user> 
<A: predecessor name="Task_2" /> 
< A: successor name="Task„5" /> 
</A:task> 

- <A:task activityID="1526" caption^ "Serial 2" 

link="Sample_Project_Plans/Ser!al_And„Parallel/TasK„5.xmr name="Task_5" 
owner= "Worker" 

processURL="http://localhost:8080/webdav/ProcessGroup2/Processl.xmr 

type="general" userld="JIC> 
<A:start>2001 8 2 18</A:start> 
<A:finIsh>2001 8 3 18</A:fin(sh> 
<A:supertask name="TasK_l*' /> 

< A: user>3K</A : user> 

< A: predecessor name="Task_3" /> 
< A: predecessor name="Task_4" /> 
</A:task> 

- <A:task activityID="NONE" caption="Serial And Parallel" 

llnk="Sample_Project_Plans/Serlal„And„Parane!/Task_l.xmr name="Task^l'' 
processURL="http://locarhost:80S0/webdav/ProcessGroup2/Processl.xmr' 
type-"general" userId="3IC> 

<A:start>2001 8 1 8</A:start> 

<A:finish>200X 8 3 18</A:fin!sh> 

< A: user>3K</A: user> 
<A:subtask name="Task_2" /> 
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^ 6104 

<?xml version="1.0" encodlng="inT-8** 7> . 
- <A;FlIePropertyMap xmIns:A=''adrenaIin:''> _y 

<A:factstaft xmlnsrA^'workflow^^aOOl S 1 9</A:factstart> 
<A:factfinish xmIns:A==*'workfIow*>2001 S 1 14</A:factnnish> 
<A:ProjectTask xmlnsiA^^Serlal I'' /> \ 
</A:FllePropertyMap> ^6106 
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<?xml version="1.0" encoding="UTF-8" ?> . 
<A:Fi!ePropertyMap xmlns:A=''adrenalin:"> ^ 

<A:factstart xmlns:A=*workflow''>2001 8 1 14</A:factstart> 
<A:factrmlsh xmlns:A="worknow''>2001 S 2 p</A:factfinIsh> 
<A:ProjectTask xmlnsiA^^Parallel 1" /^n J 
<A:ProjectTask xmJns:A=="ParaIlel 2''/>\ 
</A:FilePropertyMap> / \ 6308 
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